Bug 996813 - Review Request: SQLCipher - Encrypted SQLite databases
Review Request: SQLCipher - Encrypted SQLite databases
Status: CLOSED DUPLICATE of bug 1310294
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-08-13 22:57 EDT by Abel Luck
Modified: 2016-03-10 05:02 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-07-21 10:48:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Abel Luck 2013-08-13 22:57:22 EDT
This is my first package review request, so I'll be needing a sponsor if possible. I've based this package of the latest sqlite package sources for Fedora 19.
Spec URL: https://github.com/abeluck/fedora-sqlcipher/raw/master/sqlcipher.spec
SRPM URL: https://github.com/abeluck/fedora-sqlcipher/raw/bins/sqlcipher-2.2.1-1.fc18.src.rpm
 SQLCipher is a C library that implements an encryption in the SQLite 3
 database engine. Programs that link with the SQLCipher library can have SQL
 database access without running a separate RDBMS process. It allows one to
 have per-database or page-by-page encryption using AES-256 from Open

 SQLCipher has a small footprint and great performance so it’s ideal for
 protecting embedded application databases and is well suited for mobile
  * as little as 5-15% overhead for encryption
  * 100% of data in the database file is encrypted
  * Uses good security practices (CBC mode, key derivation)
  * Zero-configuration and application level cryptography
  * Algorithms provided by the peer reviewed OpenSSL crypto library.

 SQLCipher has broad platform support for with C/C++, Obj-C, QT, Win32/.NET,
 Java, Python, Ruby, Linux, Mac OS X, iPhone/iOS, Android, Xamarin.iOS, and

Fedora Account System Username: abelxluck

Output of rpmlint:

$ rpmlint SPECS/sqlcipher.spec RPMS/x86_64/sqlcipher-* SRPMS/sqlcipher-2.2.1-1.fc18.src.rpm 
sqlcipher.x86_64: W: spelling-error %description -l en_US crypto -> crypt, crypts, crypt o
sqlcipher.x86_64: W: spelling-error %description -l en_US iOS -> OS, SOS, DOS
sqlcipher-devel.x86_64: W: spelling-error Summary(en_US) embeddable -> embedded
sqlcipher-devel.x86_64: W: no-documentation
sqlcipher-tcl.x86_64: W: spelling-error Summary(en_US) embeddable -> embedded
sqlcipher-tcl.x86_64: W: no-documentation
sqlcipher.src: W: spelling-error %description -l en_US crypto -> crypt, crypts, crypt o
sqlcipher.src: W: spelling-error %description -l en_US iOS -> OS, SOS, DOS
5 packages and 1 specfiles checked; 0 errors, 8 warnings.

Link to successful koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5813236
Comment 1 Christopher Meng 2013-08-13 23:00:52 EDT
Are you going to support EPEL?
Comment 2 Abel Luck 2013-10-26 07:18:10 EDT
Hm, I hadn't thought to. This would be my first time maintaining a package.

Is the package more likely to be accepted if I support EPEL?  I'd need to look into the workload required to support it.
Comment 3 Björn 'besser82' Esser 2013-10-26 08:00:20 EDT
That usually has no affect whether you want to build for EPEL or not.  The _real_ problem here is:  Your package ships a bundled sqlite-version and that's something which is strongly discouraged.  See:  https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

You should actually unbundle `sqlite` and build this against the one shipped by the system's libs.

BTW. Christopher's question was about the presence of `rm -rf %{buildroot}` on %install and %check and the presence of Group: and BuildRoot: tags...

Those are simply not needed, but for <= el5.  You can safely drop `defattr`, because this was needed on <= el4.
Comment 4 Björn 'besser82' Esser 2013-10-26 08:02:51 EDT
The next problem related to the bundled `sqlite` is:  They way it get's packaged will simply conflict with system's installation of sqlite and thus is another no-go and will cause _serious_ trouble to other software which is build against system's version of sqlite..
Comment 5 Abel Luck 2013-10-26 10:40:01 EDT
Thanks Björn!

1. I believe SQLCipher deserves a No Bundled Libraries exception, so I'm preparing an exception request. Once that's submitted, I'll link it here.

2. The reason for the EPEL looking code is because I based this package off the existing sqlite package. Should I remove them if I don't plan on supporting EPEL?

3. I don't believe SQLCipher will conflict with the system's sqlite. There are no file path conflicts. Moreover, I have sqlite, sqlite-devel, sqlcipher, and sqlcipher-devel installed simultaneously on my dev system with no conflicts.

4. A new version of SQLCipher has been released since I created the package, I'll be updating it next week. Now that I have a space on fedorapeople.org, I'll upload the new sources there.

You can see this from the rpmls output below.

[user@fedora-pkg rpmbuild]$ rpmls RPMS/x86_64/sqlcipher-devel-2.2.1-1.fc18.x86_64.rpm 
-rw-r--r--  /usr/include/sqlcipher/sqlite3.h
-rw-r--r--  /usr/include/sqlcipher/sqlite3ext.h
lrwxrwxrwx  /usr/lib64/libsqlcipher.so
-rw-r--r--  /usr/lib64/pkgconfig/sqlcipher.pc
[user@fedora-pkg rpmbuild]$ rpmls RPMS/x86_64/sqlcipher-2.2.1-1.fc18.x86_64.rpm 
-rwxr-xr-x  /usr/bin/sqlcipher
lrwxrwxrwx  /usr/lib64/libsqlcipher.so.0
-rwxr-xr-x  /usr/lib64/libsqlcipher.so.0.8.6
drwxr-xr-x  /usr/share/doc/sqlcipher-2.2.1
-rw-r--r--  /usr/share/doc/sqlcipher-2.2.1/LICENSE
-rw-r--r--  /usr/share/doc/sqlcipher-2.2.1/README
-rw-r--r--  /usr/share/man/man1/sqlcipher.1.gz
[user@fedora-pkg rpmbuild]$ rpmls RPMS/x86_64/sqlcipher-tcl-2.2.1-1.fc18.x86_64.rpm 
drwxr-xr-x  /usr/lib64/tcl8.5/sqlcipher
-rwxr-xr-x  /usr/lib64/tcl8.5/sqlcipher/libtclsqlite3.so
-rw-r--r--  /usr/lib64/tcl8.5/sqlcipher/pkgIndex.tcl
Comment 6 Christopher Meng 2014-02-11 03:36:42 EST
Any news here?
Comment 7 Julian D 2015-04-23 09:23:33 EDT
definitely missing in the repo,no one willing to back it ?
Comment 8 Miroslav Suchý 2015-07-21 10:48:07 EDT
Closing due long inactivity. Feel free to reopen if you want to continue.
Comment 9 Raphael Groner 2016-03-10 05:02:58 EST

*** This bug has been marked as a duplicate of bug 1310294 ***

Note You need to log in before you can comment on or make changes to this bug.