Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 996813 - Review Request: SQLCipher - Encrypted SQLite databases
Summary: Review Request: SQLCipher - Encrypted SQLite databases
Status: CLOSED DUPLICATE of bug 1310294
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-08-14 02:57 UTC by Abel Luck
Modified: 2016-03-10 10:02 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-07-21 14:48:07 UTC

Attachments (Terms of Use)

Description Abel Luck 2013-08-14 02:57:22 UTC
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:
 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:

Comment 1 Christopher Meng 2013-08-14 03:00:52 UTC
Are you going to support EPEL?

Comment 2 Abel Luck 2013-10-26 11:18:10 UTC
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 12:00:20 UTC
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:

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 12:02:51 UTC
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 14:40:01 UTC
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, 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/
-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/
-rwxr-xr-x  /usr/lib64/
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/
-rw-r--r--  /usr/lib64/tcl8.5/sqlcipher/pkgIndex.tcl

Comment 6 Christopher Meng 2014-02-11 08:36:42 UTC
Any news here?

Comment 7 Julian D 2015-04-23 13:23:33 UTC
definitely missing in the repo,no one willing to back it ?

Comment 8 Miroslav Suchý 2015-07-21 14:48:07 UTC
Closing due long inactivity. Feel free to reopen if you want to continue.

Comment 9 Raphael Groner 2016-03-10 10:02:58 UTC

*** 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.