[Buildroot] [PATCH v3] ca-certificates: new package

[Buildroot] [PATCH v3] ca-certificates: new package

[Martin Bark]

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

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))
-- 
1.7.9.5

[Buildroot] [PATCH v3] ca-certificates: new package

[Yann E. MORIN]

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 E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ca-certificates: new package

[Peter Korsgaard]

>>>>> "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).

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v3] ca-certificates: new package

[Yann E. MORIN]

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 E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ca-certificates: new package

[Peter Korsgaard]

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

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v3] ca-certificates: new package

[Yann E. MORIN]

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 E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ca-certificates: new package

[Peter Korsgaard]

>>>>> "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/..

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v3] ca-certificates: new package

[Peter Korsgaard]

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

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v3] ca-certificates: new package

[Yann E. MORIN]

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 E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ca-certificates: new package

[Peter Korsgaard]

>>>>> "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?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v3] ca-certificates: new package

[Martin Bark]

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

[Buildroot] [PATCH v3] ca-certificates: new package

[Yann E. MORIN]

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 E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ca-certificates: new package

[Peter Korsgaard]

>>>>> "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

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v3] ca-certificates: new package

[Bernd Kuhls]

"Yann E. MORIN" <yann.morin.1998@free.fr> wrote in
news:20140112200937.GC3374 at 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

[Buildroot] [PATCH v3] ca-certificates: new package

[Yann E. MORIN]

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

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3] ca-certificates: new package

[Arnout Vandecappelle]

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

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F