Publish a release

[bricelam]

Open questions:

• What should the version be?
  • 1.0.0 (its own independent version)
  • 1.7.x (following the version of SQLite3 Multiple Ciphers)
  • 2.1.x (following the version of SQLitePCLRaw)
  • We should probably mention the version of SQLite3 Multiple Ciphers and the version of SQLite it's basded on in the package description
• What should the prerelease label be?
  • alpha.1
  • beta.1
  • preview.1
  • rc.1
• Should we codesign any of it? (probably not)

Things to ensure:

• Deterministic build is enabled Confirmed. The builds from GitHub Actions enable this.

[utelle]

Open questions:

• What should the version be?
• 1.0.0 (its own independent version)

An independent version number has its pros and cons. On one hand it allows to publish new releases if bugs are fixed or features are added in this repo, without version number clashes. On the other hand it gives no hint which version of the underlying components are used.

• 1.7.x (following the version of SQLite3 Multiple Ciphers)

This should work most of the time, because typically we will make a new release for each new release of SQLite3 Multiple Ciphers. The question is what the version number should be, if we have to make additional releases for the NuGet packages for whatever reasons.

• 2.1.x (following the version of SQLitePCLRaw)

If our packages would be an integral part of Eric's SQLitePCLRaw project, it would probably make sense to follow its version numbers. However, this is not the case and would therefore just add another level of version numbers:

1. SQLitePCLRaw version
2. SQLite3 Multiple Ciphers version
3. SQLite version

OTOH we should probably mention to which SQLitePCLRaw version our version is compatible.

• We should probably mention the version of SQLite3 Multiple Ciphers and the version of SQLite it's based on in the package description

Yes, if we use an independent version number, we should mention both, the SQLite3 Multiple Ciphers version and the SQLite version.

• What should the prerelease label be?
  * alpha.1
  * beta.1
  * preview.1
  * rc.1

IMHO we should use rc.1 (or preview.1), because using alpha or beta could give the impression that the underlying encryption extension is in alpha or beta state.

• Should we codesign any of it? (probably not)

The binaries I release with SQLite3 Multiple Ciphers are not codesigned. I don't have a codesign certificate, and as a private person it is almost impossible to get one, except one creates a self-signed certificate.

However, I don't know what users of NuGet packages expect.

[bricelam]

we should probably mention to which SQLitePCLRaw version our version is compatible

This is made clear by the package dependencies.

I don't have a codesign certificate

The cheapest I've found is Certum's certificate for open source, but I only use it when it's displayed prominently in the UI.

I don't know what users of NuGet packages expect.

Most individuals don't sign their NuGet packages. NuGet.org lists the uploader, and obviously you can't upload packages already owned by other users. They also server-sign the packages, so you know the originally uploaded bits haven't been tampered with.

Regarding the version, I like the idea of just starting at 1.0. We add the other versions in the package description.

[utelle]

I don't have a codesign certificate

The cheapest I've found is Certum's certificate for open source, but I only use it when it's displayed prominently in the UI.

I know of Certum's open source certificates. However, as far as I understood the certificate is only valid for a single open source project, and the required identification process is extremely cumbersome. Actually, I tried it several years ago and failed eventually (after many mails and phone calls going back and forth).

Most individuals don't sign their NuGet packages. NuGet.org lists the uploader, and obviously you can't upload packages already owned by other users. They also server-sign the packages, so you know the originally uploaded bits haven't been tampered with.

That should be good enough for us, too.

Regarding the version, I like the idea of just starting at 1.0. We add the other versions in the package description.

I'm fine with that approach.

[ericsink]

FYI -- after taking a closer look at this effort, I'm starting to understand the appeal of SQLite3 Multiple Ciphers. It's got me wondering about if/how I might want to connect with what you folks are doing here.

[utelle]

FYI -- after taking a closer look at this effort, I'm starting to understand the appeal of SQLite3 Multiple Ciphers. It's got me wondering about if/how I might want to connect with what you folks are doing here.

@ericsink I tried to reach out to you about a month ago, but didn't get a response. So, I started with this project on my own with active support of @bricelam.

Actually, I forked your repo ericsink/cb for generating the binaries for my SQLite3 Multiple Ciphers library. And that works very well. However, I failed to adjust your repo ericsink/SQLitePCL.raw. So, @bricelam helped to set up this separate repo.

We are almost ready to publish a first pre-release. We intend(ed) to use the package name SQLitePCLRaw.bundle_sqlite3mc, but we are unsure whether this will work, because NuGet.org indicates for your packages that they use a reserved ID prefix, and that packages of other owners using the same prefix might be rejected. And we don't know how you set up the ID prefix reservation.

So, one way you could connect with this project would be to allow using your ID prefix.

Of course, I'm open to other forms of cooperation. Just let me know your thoughts about this endeavor.

[bricelam]

@ericsink I was working under the assumption that you weren't eager to take on yet another flavor of SQLite directly. But if this is something you'd like to see in the main SQLitePCLRaw repos, let us know.

Because it's compatible with SQLCipher, this may give you a path forward for deprecating your e_sqlcipher packages. (If that's something you'd like to do.)

[ericsink]

First of all, my apologies for failing to respond. The last 5 months have been very hectic on another project. That project is not done, but now it's giving me some breathing room, so today I decided to start catching up on SQLitePCLRaw stuff.

I remember seeing SQLite3 Multiple Ciphers at some point in the past. Initially I wasn't very interested, because it seemed related to the area of SQLitePCLRaw which I find most troublesome (sqlcipher).

But like I said, I'm seeing some appeal.

One of the things I most dislike is that my e_sqlcipher builds are competing with Zetetic, which does all the work of developing sqlcipher and charges money for supported builds. I wrote a wiki page somewhere about the history of how I got into this mess. For quite some time I have wanted to just stop doing sqlcipher builds and tell everyone to go buy them from Zetetic, but I have never quite talked myself into that.

Today I started wondering if supporting sqlite3mc might be the first step. I love the fact that you're already building an amalgamation, and that you've got integration with my (ridiculously quirky) cb repo.

So, I allowed myself to ponder such things. And one of my first concerns was to figure out how to explore the possibilities without being a jerk. I don't want to be presumptuous. I want to be sure that any cooperation includes the proper level of credit and respect for the work you (et al) have done.

One way that I may continue to be a jerk is about that nuget reserved ID prefix: For the moment, and I may change my mind, I don't think I want to allow that prefix to be used on a package for which I have no responsibility.

I'm still thinking about all this, but hopefully this comment adds more thoughts to the conversation.

[ericsink]

(I saw Brice's comment after writing mine.)

[bricelam]

One thing we've tried to do to mitigate the ownership confusion is add the following to our package descriptions:

NOTICE! This package is maintained separately from the SQLitePCLRaw project.

[utelle]

First of all, my apologies for failing to respond.

No problem. I fully understand your position.

I remember seeing SQLite3 Multiple Ciphers at some point in the past. Initially I wasn't very interested, because it seemed related to the area of SQLitePCLRaw which I find most troublesome (sqlcipher).

Actually, all started with my project wxSQLite3 about 18 years ago. I had a high demand for securing the databases of one of my projects. The official SQLite Encryption Extension (SEE) was too expensive for a non-profit project. So I started with my own AES128-CBC encryption extension. Later I added AES256-CBC. wxSQLite3 used the SQLite encryption API that was part of the public SQLite distribution until early 2020. The removal of the SQLite encryption API forced me to find another solution - this is one reason why I started with SQLite3 Multiple Ciphers.

In the past I was asked several times whether I could add support for the SQLCipher cipher scheme. Having my wxSQLite3 implementation at hand I found out that this could be accomplished with not too big effort. So, now SQLite3 Multiple Ciphers can read and write all SQLCipher database variants from version 1 up to version 4. However, I support only the open-source variant of SQLCipher. The commercial extensions are not supported, and SQLCipher's special pragma commands are mostly not supported, at least not with the same names. The goal of my implementation was to support reading and writing SQLCipher encrypted databases, but not to implement a SQLCipher library clone.

One of the things I most dislike is that my e_sqlcipher builds are competing with Zetetic, which does all the work of developing sqlcipher and charges money for supported builds. I wrote a wiki page somewhere about the history of how I got into this mess.

I would like to read that wiki page. Can you provide a link?

For quite some time I have wanted to just stop doing sqlcipher builds and tell everyone to go buy them from Zetetic, but I have never quite talked myself into that.

I never bothered to use or build Zetetic's library.

Today I started wondering if supporting sqlite3mc might be the first step. I love the fact that you're already building an amalgamation, and that you've got integration with my (ridiculously quirky) cb repo.

Yeah, it took some time to integrate sqlite3mc into the cb build process, but in the end it worked. 😄

So, I allowed myself to ponder such things. And one of my first concerns was to figure out how to explore the possibilities without being a jerk. I don't want to be presumptuous. I want to be sure that any cooperation includes the proper level of credit and respect for the work you (et al) have done.

Could you elaborate in more detail, what a proper level of credit would be for you?

One way that I may continue to be a jerk is about that nuget reserved ID prefix: For the moment, and I may change my mind, I don't think I want to allow that prefix to be used on a package for which I have no responsibility.

I can understand that. I would see it the same in your place. Especially, because NuGet's management of ID prefixes is quite coarse-grained - actually an "all or (n)one" approach.

So, we will have to rename our NuGet package. However, IMHO the name should somehow reflect that the package is closely linked to your work, SQLitePCLRaw.

[ericsink]

I would like to read that wiki page. Can you provide a link?

https://github.com/ericsink/SQLitePCL.raw/wiki/Expectation-setting-for-e_sqlcipher

Could you elaborate in more detail, what a proper level of credit would be for you?

My concern is proper credit for YOU, not me.

Let's try the discussion this way:

What if you and Brice were to convert all this into a couple of pull requests for my cb and SQLitePCL.raw repos? What concerns would you have?

[bricelam]

What concerns would you have?

None here. As far as I'm concerned, this is just a bunch of XML I threw together to help @utelle distribute to C#/.NET developers on NuGet.org.

Some things @utelle might want to consider:

• What license would the binaries be released under?
• How up-to-date will releases be? Would you be willing to publish a new release every time SQLite3 Multiple Ciphers releases?

[utelle]

I would like to read that wiki page. Can you provide a link?

https://github.com/ericsink/SQLitePCL.raw/wiki/Expectation-setting-for-e_sqlcipher

Thanks. Very interesting.

I feel tempted to add several comments, but I stick to just make a few remarks about encryption security.

Currently, all SQLite encryption extensions I know of suffer from the same limitations as the official SQLite Encryption Extension (SEE), namely:

1. TEMP tables are not encrypted.
2. In-memory (":memory:") databases are not encrypted.

This is true for SQLCipher. And for SQLite3 Multiple Ciphers, too. That is, if a user does not enforce that temporary data are only held in memory, security is flawed - at least on the machine where the application is running. However, the database files themselves are secure as long as the user uses strong passphrases and keeps them separated from the database files.

SEE has a 3rd limitation:

3. Bytes 16 through 23 of the database file contain header information which is not encrypted.

The reason is that those bytes contain information about the database page size. This information is needed, before any database information can be decrypted.

SQLCipher encrypts those bytes, too. As a consequence a user must issue a pragma telling SQLite the actual page size, if a non-default page size is used, because the library can not retrieve that information from the database file.

SQLite Multiple Ciphers obeys the 3rd limitation, but supports what I call legacy modes which allow to access original SQLCipher or sqleet database files (if the page size is known).

Could you elaborate in more detail, what a proper level of credit would be for you?

My concern is proper credit for YOU, not me.

If my project SQLite3 Multiple Ciphers (and maybe my name) is mentioned and if a link to the SQLite3 Multiple Ciphers GitHub repo is added, I'm fine.

Let's try the discussion this way:

What if you and Brice were to convert all this into a couple of pull requests for my cb and SQLitePCL.raw repos? What concerns would you have?

I can mainly speak only for the cb repo, because I did all necessary modifications to make it build the sqlite3mc binaries. I guess it would be no big deal to make pull requests for your cb repo.

My concern would simply be about the publishing process. Usually I publish new sqlite3mc releases shortly after the release of a new SQLite version, and it would be nice if dependent components are published at more or less the same pace.

About the SQLitePCLraw repo @bricelam should comment, because he did most of the work for the .NET layer. If I understood him correctly, our new repo deviates considerably from SQLitePCLraw, although it uses SQLitePCLraw to a certain degree to generate the bindings.

I myself tried to add sqlite3mc support to a fork of your SQLitePCLraw repo, but failed. However, the reason was most likely that I'm far from being a .NET expert.

[utelle]

Some things @utelle might want to consider:

• What license would the binaries be released under?

AFAICS the SQLitePCLraw packages are released under the Apache 2.0 license. SQLite3 Multiple Ciphers is released under the MIT license. AFAIK Apache 2.0 and MIT licenses are compatible with each other.

• How up-to-date will releases be? Would you be willing to publish a new release every time SQLite3 Multiple Ciphers releases?

Well, if SQLitePCLraw releases less frequently, it will be Eric who has to deal with user complaints.