| Message ID | 1389368384-1332-1-git-send-email-martin@barkynet.com |
|---|---|
| State | Accepted |
| Headers | show |
Martin, All, On 2014-01-10 15:39 +0000, Martin Bark spake thusly: [--SNIP--] > diff --git a/package/ca-certificates/ca-certificates.mk b/package/ca-certificates/ca-certificates.mk > new file mode 100644 > index 0000000..37ed746 > --- /dev/null > +++ b/package/ca-certificates/ca-certificates.mk > @@ -0,0 +1,37 @@ > +################################################################################ > +# > +# ca-certificates > +# > +################################################################################ > + > +CA_CERTIFICATES_VERSION = 20130906 > +CA_CERTIFICATES_SOURCE = ca-certificates_$(CA_CERTIFICATES_VERSION).tar.gz > +CA_CERTIFICATES_SITE = http://snapshot.debian.org/archive/debian/20130907T154615Z/pool/main/c/ca-certificates It's a pity we can't get that from a trusted channel (ie. https instead of plain http). Sigh... :-( I know we do not do that for the other packages, but I'd like that we check the authenticity of that specific one. There's no point in adding a security-related package that we can validate in the first place. I'd suggest we do that with a _POST_DOWNLOAD_HOOKS, something like: CA_CERTIFICATES_CHECKSUM = SHA1-hash define CA_CERTIFICATES_VERIFY_CHECKSUM hash=$$( sha1sum $(DL_DIR)/$(CA_CERTIFICATES_SOURCE) |cut -d ' ' -f 1 ) if [ ! $${hash} = $(CA_CERTIFICATES_CHECKSUM) ]; then printf "ERROR: $(CA_CERTIFICATES_SOURCE) has wrong SHA1\n" printf "ERROR: Maybe the download was MITMed\n" exit 1 fi endef CA_CERTIFICATES_POST_DOWNLOAD_HOOKS += CA_CERTIFICATES_VERIFY_CHECKSUM I don't know what others think of it. Peter, Thomas, others? > +define CA_CERTIFICATES_INSTALL_TARGET_CMDS > + $(INSTALL) -d -m 0755 $(TARGET_DIR)/usr/share/ca-certificates > + $(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/ssl/certs > + $(MAKE) -C $(@D) install DESTDIR=$(TARGET_DIR) > + rm -f $(TARGET_DIR)/usr/sbin/update-ca-certificates > + > + #remove any existing certificates under /etc/ssl/certs Usually, we add a space after the sharp symbol, and we start comments with an uppercase letter, as for all sentences: # Remove any existing certificates under /etc/ssl/certs > + rm -f $(TARGET_DIR)/etc/ssl/certs/* [--SNIP--] > + #create symlinks to certificates under /etc/ssl/certs Comment: ditto. > + cd $(TARGET_DIR) ;\ > + for i in `find usr/share/ca-certificates -name "*.crt"` ; do \ > + ln -sf ../../../$$i etc/ssl/certs/`basename $${i} .crt`.pem ;\ > + done ;\ That last trailing ';\' is unneeded. It works because you have a empty line below. > + #create symlinks to the certificates by their hash values Comment: ditto. Regards, Yann E. MORIN.
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hi, > It's a pity we can't get that from a trusted channel (ie. https instead > of plain http). Sigh... :-( > I know we do not do that for the other packages, but I'd like that we > check the authenticity of that specific one. There's no point in adding > a security-related package that we can validate in the first place. > I'd suggest we do that with a _POST_DOWNLOAD_HOOKS, something like: > CA_CERTIFICATES_CHECKSUM = SHA1-hash > define CA_CERTIFICATES_VERIFY_CHECKSUM > hash=$$( sha1sum $(DL_DIR)/$(CA_CERTIFICATES_SOURCE) |cut -d ' ' -f 1 ) > if [ ! $${hash} = $(CA_CERTIFICATES_CHECKSUM) ]; then > printf "ERROR: $(CA_CERTIFICATES_SOURCE) has wrong SHA1\n" > printf "ERROR: Maybe the download was MITMed\n" > exit 1 > fi > endef > CA_CERTIFICATES_POST_DOWNLOAD_HOOKS += CA_CERTIFICATES_VERIFY_CHECKSUM > I don't know what others think of it. Peter, Thomas, others? If we want to do something like this, then I would much prefer to move it into the package infrastructure and do it for all packages (but not require it, similar to how we're progressively adding licensing info to packages).
Peter, All, On 2014-01-12 09:38 +0100, Peter Korsgaard spake thusly: > >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: > > It's a pity we can't get that from a trusted channel (ie. https instead > > of plain http). Sigh... :-( > > > I know we do not do that for the other packages, but I'd like that we > > check the authenticity of that specific one. There's no point in adding > > a security-related package that we can validate in the first place. > > > I'd suggest we do that with a _POST_DOWNLOAD_HOOKS, something like: > > > CA_CERTIFICATES_CHECKSUM = SHA1-hash > > define CA_CERTIFICATES_VERIFY_CHECKSUM > > hash=$$( sha1sum $(DL_DIR)/$(CA_CERTIFICATES_SOURCE) |cut -d ' ' -f 1 ) > > if [ ! $${hash} = $(CA_CERTIFICATES_CHECKSUM) ]; then > > printf "ERROR: $(CA_CERTIFICATES_SOURCE) has wrong SHA1\n" > > printf "ERROR: Maybe the download was MITMed\n" > > exit 1 > > fi > > endef > > CA_CERTIFICATES_POST_DOWNLOAD_HOOKS += CA_CERTIFICATES_VERIFY_CHECKSUM > > > I don't know what others think of it. Peter, Thomas, others? > > If we want to do something like this, then I would much prefer to move > it into the package infrastructure and do it for all packages (but not > require it, similar to how we're progressively adding licensing info to > packages). Eh! I knew you'd say that! :-) I guess there's no point in adding such a check for git, svn and all other VCSes. Only 'static' content wouls be elligible to being checked. Regards, Yann E. MORIN.
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hi, >> If we want to do something like this, then I would much prefer to move >> it into the package infrastructure and do it for all packages (but not >> require it, similar to how we're progressively adding licensing info to >> packages). > Eh! I knew you'd say that! :-) ;) > I guess there's no point in adding such a check for git, svn and all > other VCSes. Only 'static' content wouls be elligible to being checked. Why not? I know git gives you strong integrity guarantees (if you use the sha1 atleast), but E.G. svn doesn't.
Peter, All, On 2014-01-12 19:23 +0100, Peter Korsgaard spake thusly: > >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: > > I guess there's no point in adding such a check for git, svn and all > > other VCSes. Only 'static' content wouls be elligible to being checked. > > Why not? I know git gives you strong integrity guarantees (if you use > the sha1 atleast), but E.G. svn doesn't. Because we can't guarantee the reproducibility of an archive generated by git archive, since at least the file's date may change, end up in the tarball, and thus generate a different hash, even if the 'content' of the archive is the same. Also, a different git version may re-order the files, or whatever. For a VCS, maybe the list of files and their respective contents are OK, but we can't say anything about the generated archive. Regards, Yann E. MORIN.
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hi, >> > I guess there's no point in adding such a check for git, svn and all >> > other VCSes. Only 'static' content wouls be elligible to being checked. >> >> Why not? I know git gives you strong integrity guarantees (if you use >> the sha1 atleast), but E.G. svn doesn't. > Because we can't guarantee the reproducibility of an archive generated > by git archive, since at least the file's date may change, end up in the > tarball, and thus generate a different hash, even if the 'content' of > the archive is the same. Also, a different git version may re-order the > files, or whatever. Ahh, yes. > For a VCS, maybe the list of files and their respective contents are OK, > but we can't say anything about the generated archive. True. If we implement it like _LICENSE, we can probably just not add those tags for packages using git/hg/svn/..
>>>>> "Martin" == Martin Bark <martin@barkynet.com> writes: > CA certificates used for SSL based applications. The package installs CA > certificates to /usr/share/ca-certificates and creates symbolic links under > /etc/ssl/certs. For example, the existing libcurl package will use these > certificates for https urls. Based on the debian ca-certifcates package. > Signed-off-by: Martin Bark <martin@barkynet.com> Committed with Yann's comment taken into account, thanks.
Peter, All, On 2014-01-12 20:19 +0100, Peter Korsgaard spake thusly: > >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: > >> > I guess there's no point in adding such a check for git, svn and all [--SNIP--] > > For a VCS, maybe the list of files and their respective contents are OK, > > but we can't say anything about the generated archive. > > True. If we implement it like _LICENSE, we can probably just not add > those tags for packages using git/hg/svn/.. I've already started implementing that, and it looks like we have a problem. The problem is that some packages have more than one download: - the tarball itself - optional patches, by way of PKG_PATCH - additional files, by way of PKG_EXTRA_DOWNLOADS So, if we want to implement it at all, we have to provide the check for those other downloads too. And a variable is not enough. Another solution would be to annotate each file with its hash, someting like: foo-1.2.3.patch:ABCDEF1234567890 bla.patch:ABCDEF1234567890 \ file.bin:ABCDEF1234567890 This is ugly, and very convenient either. An third alternative is to add a package/pkg/pkg.hash file, which contains the list of files, and their hashes; in fact, the output of the hash util we'd use: ABCDEF1234567890 foo-1.2.3.patch ABCDEF1234567890 bla.patch ABCDEF1234567890 file.bin So, it indeed adds a third file to the existing pkg.mk and Config.in, but it looks like it is the cleanest solution to me, and the one I've started implementing. Also, we'd have to settle for a hash function. md5 is outdated and subject to attacks; sha1 is still current, but there are known potential attacks; sha2/256 is still very strong for the foreseeable future; sha2/512 seems like a bit overkill, although the time to hash is not very different between sha2/256 and sha2/512. This can be very easily changed, so I've settled for sha2/256 for now. Regards, Yann E. MORIN.
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hi, > An third alternative is to add a package/pkg/pkg.hash file, which > contains the list of files, and their hashes; in fact, the output of the > hash util we'd use: > ABCDEF1234567890 foo-1.2.3.patch > ABCDEF1234567890 bla.patch > ABCDEF1234567890 file.bin That sounds good to me, and is easy to handle. Another alternative would be to make <pkg>_CHECKSUM a list of hashes, in the same order as the files are handled (_SOURCE, _EXTRA_DOWNLOADS, _PATCH). > Also, we'd have to settle for a hash function. md5 is outdated and > subject to attacks; sha1 is still current, but there are known potential > attacks; sha2/256 is still very strong for the foreseeable future; > sha2/512 seems like a bit overkill, although the time to hash is not > very different between sha2/256 and sha2/512. > This can be very easily changed, so I've settled for sha2/256 for now. Next to their strength is also the issue about how likely it is that those tools are available on the build host. As we would like to check the hash before downloading, it wouldn't work very well if we needed to build a host-sha2 or similar. I don't know what's available on E.G. RHEL, but perhaps sha1 is a safer bet?
Woo hoo, my first contribution to buildroot. Thanks Peter. I was just about to send a v4 patch so you saved me a job :) On 12/01/14 20:09, Peter Korsgaard wrote: >>>>>> "Martin" == Martin Bark <martin@barkynet.com> writes: > > > CA certificates used for SSL based applications. The package installs CA > > certificates to /usr/share/ca-certificates and creates symbolic links under > > /etc/ssl/certs. For example, the existing libcurl package will use these > > certificates for https urls. Based on the debian ca-certifcates package. > > > Signed-off-by: Martin Bark <martin@barkynet.com> > > Committed with Yann's comment taken into account, thanks. >
Peter, All, On 2014-01-12 21:32 +0100, Peter Korsgaard spake thusly: > >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: > > An third alternative is to add a package/pkg/pkg.hash file, which > > contains the list of files, and their hashes; in fact, the output of the > > hash util we'd use: > > ABCDEF1234567890 foo-1.2.3.patch > > ABCDEF1234567890 bla.patch > > ABCDEF1234567890 file.bin > > That sounds good to me, and is easy to handle. Another alternative would > be to make <pkg>_CHECKSUM a list of hashes, in the same order as the > files are handled (_SOURCE, _EXTRA_DOWNLOADS, _PATCH). And how do you suggest we correlate the hash from that list to the file we're actually just downloaded? The tarball is in one variable, the patches in a second, and the extra files in a third. We'd have to look in each of those variables to find the file, and derive an offset in the list form that, and then extract the n-th element of that list. I guess this is not so easy as you think it is. ;-) > > Also, we'd have to settle for a hash function. [--SNIP--] > Next to their strength is also the issue about how likely it is that > those tools are available on the build host. Right, those pesky companies using "Enterprise Editions" and then stuck back in the 20th century... ;-] sha1 shall it be, then. ;-) (Note: sha2 was added to coreutils seven years ago, 2005-10-23) Regards, Yann E. MORIN.
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hi, > And how do you suggest we correlate the hash from that list to the file > we're actually just downloaded? > The tarball is in one variable, the patches in a second, and the extra > files in a third. > We'd have to look in each of those variables to find the file, and > derive an offset in the list form that, and then extract the n-th > element of that list. > I guess this is not so easy as you think it is. ;-) I guess not ;) As I said, a seperate <pkg>.hash is OK as well. >> > Also, we'd have to settle for a hash function. > [--SNIP--] >> Next to their strength is also the issue about how likely it is that >> those tools are available on the build host. > Right, those pesky companies using "Enterprise Editions" and then stuck > back in the 20th century... ;-] Indeed. > sha1 shall it be, then. ;-) > (Note: sha2 was added to coreutils seven years ago, 2005-10-23) Ahh, ok - I didn't realize it was that old. From a quick look, it seems like it's even present in RHEL5, which is probably as old as we can sanely support (are people really still using RHEL4 for development?): http://rpmfind.net//linux/RPM/centos/5.10/i386/CentOS/coreutils-5.97-34.el5_8.1.i386.html
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote in news:20140112200937.GC3374@free.fr: > An third alternative is to add a package/pkg/pkg.hash file, which > contains the list of files, and their hashes; in fact, the output of the > hash util we'd use: > ABCDEF1234567890 foo-1.2.3.patch > ABCDEF1234567890 bla.patch > ABCDEF1234567890 file.bin Hi, FYI: the Gentoo project stores file hashes like this: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/ca- certificates/Manifest?view=markup Regards, Bernd
Bernd, All, On 2014-01-12 22:21 +0100, Bernd Kuhls spake thusly: > "Yann E. MORIN" <yann.morin.1998@free.fr> wrote in > news:20140112200937.GC3374@free.fr: > > > An third alternative is to add a package/pkg/pkg.hash file, which > > contains the list of files, and their hashes; in fact, the output of the > > hash util we'd use: > > ABCDEF1234567890 foo-1.2.3.patch > > ABCDEF1234567890 bla.patch > > ABCDEF1234567890 file.bin > FYI: the Gentoo project stores file hashes like this: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/ca- > certificates/Manifest?view=markup Woah... That's much too complex for what we need... Regards, Yann E. MORIN.
On 12/01/14 19:34, Yann E. MORIN wrote: > Peter, All, > > On 2014-01-12 19:23 +0100, Peter Korsgaard spake thusly: >>>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: >> > I guess there's no point in adding such a check for git, svn and all >> > other VCSes. Only 'static' content wouls be elligible to being checked. >> >> Why not? I know git gives you strong integrity guarantees (if you use >> the sha1 atleast), but E.G. svn doesn't. > > Because we can't guarantee the reproducibility of an archive generated > by git archive, since at least the file's date may change, end up in the > tarball, and thus generate a different hash, even if the 'content' of > the archive is the same. Also, a different git version may re-order the > files, or whatever. > > For a VCS, maybe the list of files and their respective contents are OK, > but we can't say anything about the generated archive. FWIW, there exists a tool for SPDX that does exactly this: hash all files in an archive, ignoring their order and timestamp but making sure there are no more and no less files than required. But of course, that tool would have to be built as a host-tool because it isn't installed on any build machine. And I'm not even sure if the tool really exists or is just something that needs to be implemented for SPDX. Regards, Arnout
diff --git a/package/Config.in b/package/Config.in index 38db5de..f9739ba 100644 --- a/package/Config.in +++ b/package/Config.in @@ -471,6 +471,7 @@ endmenu menu "Crypto" source "package/beecrypt/Config.in" +source "package/ca-certificates/Config.in" source "package/cryptodev/Config.in" source "package/gnutls/Config.in" source "package/libassuan/Config.in" diff --git a/package/ca-certificates/Config.in b/package/ca-certificates/Config.in new file mode 100644 index 0000000..a278a62 --- /dev/null +++ b/package/ca-certificates/Config.in @@ -0,0 +1,11 @@ +config BR2_PACKAGE_CA_CERTIFICATES + bool "CA Certificates" + help + This package includes PEM files of CA certificates to allow + SSL-based applications to check for the authenticity of SSL + connections. + + It includes, among others, certificate authorities used by the + Debian infrastructure and those shipped with Mozilla's browsers. + + http://anonscm.debian.org/gitweb/?p=collab-maint/ca-certificates.git diff --git a/package/ca-certificates/ca-certificates.mk b/package/ca-certificates/ca-certificates.mk new file mode 100644 index 0000000..37ed746 --- /dev/null +++ b/package/ca-certificates/ca-certificates.mk @@ -0,0 +1,37 @@ +################################################################################ +# +# ca-certificates +# +################################################################################ + +CA_CERTIFICATES_VERSION = 20130906 +CA_CERTIFICATES_SOURCE = ca-certificates_$(CA_CERTIFICATES_VERSION).tar.gz +CA_CERTIFICATES_SITE = http://snapshot.debian.org/archive/debian/20130907T154615Z/pool/main/c/ca-certificates +CA_CERTIFICATES_DEPENDENCIES = host-openssl host-python +CA_CERTIFICATES_LICENSE = GPLv2+ (script), MPLv2.0 (data) +CA_CERTIFICATES_LICENSE_FILES = debian/copyright + +define CA_CERTIFICATES_BUILD_CMDS + $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) all +endef + +define CA_CERTIFICATES_INSTALL_TARGET_CMDS + $(INSTALL) -d -m 0755 $(TARGET_DIR)/usr/share/ca-certificates + $(INSTALL) -d -m 0755 $(TARGET_DIR)/etc/ssl/certs + $(MAKE) -C $(@D) install DESTDIR=$(TARGET_DIR) + rm -f $(TARGET_DIR)/usr/sbin/update-ca-certificates + + #remove any existing certificates under /etc/ssl/certs + rm -f $(TARGET_DIR)/etc/ssl/certs/* + + #create symlinks to certificates under /etc/ssl/certs + cd $(TARGET_DIR) ;\ + for i in `find usr/share/ca-certificates -name "*.crt"` ; do \ + ln -sf ../../../$$i etc/ssl/certs/`basename $${i} .crt`.pem ;\ + done ;\ + + #create symlinks to the certificates by their hash values + $(HOST_DIR)/usr/bin/c_rehash $(TARGET_DIR)/etc/ssl/certs +endef + +$(eval $(generic-package))
CA certificates used for SSL based applications. The package installs CA certificates to /usr/share/ca-certificates and creates symbolic links under /etc/ssl/certs. For example, the existing libcurl package will use these certificates for https urls. Based on the debian ca-certifcates package. Signed-off-by: Martin Bark <martin@barkynet.com> --- Changes v2 -> v3 - Fixed missing tabs (suggested by Thomas Petazzoni) - Added upstream url to Config.in (suggested by Thomas Petazzoni) - Changed CA_CERTIFICATES_SITE to use snapshot.debian.org (suggested by Thomas Petazzoni) - Changed PATH=$(HOST_PATH) to $(TARGET_MAKE_ENV) in build cmd (suggested by Thomas Petazzoni) - Removed parenthesis and fixed use of basename in install cmd (suggested by Yann E. MORIN) Changes v1 -> v2 - Change CA_CERTIFICATES_SITE to use $(BR2_DEBIAN_MIRROR) (suggested by Baruch Siach) - Clarify license usage in CA_CERTIFICATES_LICENSE (suggested by Baruch Siach) --- package/Config.in | 1 + package/ca-certificates/Config.in | 11 +++++++++ package/ca-certificates/ca-certificates.mk | 37 ++++++++++++++++++++++++++++ 3 files changed, 49 insertions(+) create mode 100644 package/ca-certificates/Config.in create mode 100644 package/ca-certificates/ca-certificates.mk