Skip to contentSkip to conversation

ca-certificates: new package

PATCH Superseded Martin Bark 5 participants 16 messages Jan 10, 2014 – Jan 14, 2014

lore
Share & tools
lore

Martin Bark

author
#0 lore raw

PATCH v3 1/1 ca-certificates: new 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 <[email protected]>

---
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
package/Config.in +1 -0
index 38db5de..f9739ba 100644
@@ -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"
package/ca-certificates/Config.in new file +11 -0
new file mode 100644
index 0000000..a278a62
@@ -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
package/ca-certificates/ca-certificates.mk new file +37 -0
new file mode 100644
index 0000000..37ed746
@@ -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))
Signature · 1 line
1.7.9.5
#1 lore raw

PATCH v3 1/1 ca-certificates: new package

Martin, All,

On 2014-01-10 15:39 +0000, Martin Bark spake thusly:
[--SNIP--]

Quoted 6 lines
package/ca-certificates/ca-certificates.mk new file +0 -0
new file mode 100644
index 0000000..37ed746

package/ca-certificates/ca-certificates.mk line 9

Quoted 9 lines
package/ca-certificates/ca-certificates.mk new file +9 -0
@@ -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?

package/ca-certificates/ca-certificates.mk line 24

Quoted 7 lines
package/ca-certificates/ca-certificates.mk new file +7 -0
+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

package/ca-certificates/ca-certificates.mk line 25

Quoted 1 line
package/ca-certificates/ca-certificates.mk new file +1 -0
+   rm -f  $(TARGET_DIR)/etc/ssl/certs/*

[--SNIP--]

package/ca-certificates/ca-certificates.mk line 27

Quoted 1 line
package/ca-certificates/ca-certificates.mk new file +1 -0
+	#create symlinks to certificates under /etc/ssl/certs

Comment: ditto.

package/ca-certificates/ca-certificates.mk line 31

Quoted 4 lines
package/ca-certificates/ca-certificates.mk new file +4 -0
+	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.

package/ca-certificates/ca-certificates.mk line 33

Quoted 1 line
package/ca-certificates/ca-certificates.mk new file +1 -0
+	#create symlinks to the certificates by their hash values

Comment: ditto.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#2 lore raw

PATCH v3 1/1 ca-certificates: new package

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Hi,

Quoted 17 lines

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
Quoted 4 lines

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

Signature · 1 line
Bye, Peter Korsgaard
#3 lore raw

PATCH v3 1/1 ca-certificates: new package

Peter, All,

On 2014-01-12 09:38 +0100, Peter Korsgaard spake thusly:

Quoted 21 lines
Quoted 20 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> 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

Quoted 6 lines
Quoted 1 line

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#4 lore raw

PATCH v3 1/1 ca-certificates: new package

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Hi,

Quoted 6 lines
Quoted 4 lines

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! :-)

;)

Quoted 2 lines

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.

Signature · 1 line
Bye, Peter Korsgaard
#5 lore raw

PATCH v3 1/1 ca-certificates: new package

Peter, All,

On 2014-01-12 19:23 +0100, Peter Korsgaard spake thusly:

Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> 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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#6 lore raw

PATCH v3 1/1 ca-certificates: new package

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Hi,

Quoted 11 lines
Quoted 5 lines
Quoted 2 lines

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.

Quoted 2 lines

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

Signature · 1 line
Bye, Peter Korsgaard
#7 lore raw

PATCH v3 1/1 ca-certificates: new package

Peter, All,

On 2014-01-12 20:19 +0100, Peter Korsgaard spake thusly:

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

I guess there's no point in adding such a check for git, svn and all

[--SNIP--]

Quoted 5 lines
Quoted 2 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#8 lore raw

PATCH v3 1/1 ca-certificates: new package

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Hi,

Quoted 6 lines

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

Quoted 7 lines

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?

Signature · 1 line
Bye, Peter Korsgaard
#9 lore raw

PATCH v3 1/1 ca-certificates: new package

Peter, All,

On 2014-01-12 21:32 +0100, Peter Korsgaard spake thusly:

Quoted 11 lines
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> 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. ;-)

Quoted 1 line
Quoted 1 line

Also, we'd have to settle for a hash function.

[--SNIP--]

Quoted 2 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#10 lore raw

PATCH v3 1/1 ca-certificates: new package

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Hi,

Quoted 11 lines

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.

Quoted 7 lines
Quoted 1 line
Quoted 1 line

Also, we'd have to settle for a hash function.

[--SNIP--]

Quoted 2 lines

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.

Quoted 3 lines

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

Signature · 1 line
Bye, Peter Korsgaard
#11 lore raw

PATCH v3 1/1 ca-certificates: new package

In reply to Yann E. MORIN

"Yann E. MORIN" <[email protected]> wrote in news:20140112200937.GC3374 at free.fr:

Quoted 6 lines

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

#12 lore raw

PATCH v3 1/1 ca-certificates: new package

Bernd, All,

On 2014-01-12 22:21 +0100, Bernd Kuhls spake thusly:

Quoted 9 lines

"Yann E. MORIN" <[email protected]> wrote in news:20140112200937.GC3374 at free.fr:

Quoted 6 lines

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
Quoted 4 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#13 lore raw

PATCH v3 1/1 ca-certificates: new package

In reply to Yann E. MORIN
Quoted 10 lines · Yann E. MORIN

Peter, All,

On 2014-01-12 19:23 +0100, Peter Korsgaard spake thusly:

Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> 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.

Quoted 8 lines

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

Signature · 6 lines
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
#14 lore raw

PATCH v3 1/1 ca-certificates: new package

In reply to Martin Bark
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Martin" == Martin Bark <[email protected]> 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 <[email protected]>

Committed with Yann's comment taken into account, thanks.

Signature · 1 line
Bye, Peter Korsgaard
author
#15 lore raw

PATCH v3 1/1 ca-certificates: new package

Woo hoo, my first contribution to buildroot.

Thanks Peter. I was just about to send a v4 patch so you saved me a job :)

Quoted 11 lines · Peter Korsgaard
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Martin" == Martin Bark <[email protected]> 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 <[email protected]>

Committed with Yann's comment taken into account, thanks.