documentation: hash source control archives
PATCH 1/1 documentation: hash source control archives
Archives created from source control systems should still use a hash file with a locally-computed e.g. sha256 hash. As discussed [1], using the 'none' type is no longer a best practice so update the documentation to clarify this.
[1] http://lists.busybox.net/pipermail/buildroot/2016-November/178165.html
--- docs/manual/adding-packages-directory.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
docs/manual/adding-packages-directory.txt +1 -2
@@ -480,8 +480,7 @@ this in a comment line above the hashes. The number of spaces does not matter, so one can use spaces (or tabs) to properly align the different fields. -The +none+ hash type is reserved to those archives downloaded from a -repository, like a 'git clone', a 'subversion checkout'... +For archives downloaded from a repository e.g. from a 'git clone', a 'subversion checkout', using a locally-calculated sha256 hash is recommended although the +none+ type has also been used. The example below defines a +sha1+ and a +sha256+ published by upstream for the main +libfoo-1.2.3.tar.bz2+ tarball, an +md5+ from upstream and a
Signature · 1 line
2.7.4
PATCH 1/1 documentation: hash source control archives
Hello,
docs/manual/adding-packages-directory.txt this in a comment line above the hashes. · line 483
Quoted 3 lines · Ash Charles
docs/manual/adding-packages-directory.txt +1
-2-The +none+ hash type is reserved to those archives downloaded from a -repository, like a 'git clone', a 'subversion checkout'... +For archives downloaded from a repository e.g. from a 'git clone', a 'subversion checkout', using a locally-calculated sha256 hash is recommended although the +none+ type has also been used.
The line needs to be wrapped to 72 characters.
Also, I am not sure that the archives we produce from all version control systems are reproducible. I'm sure it's the case for Git, but I'm not sure for Subversion, so it might be that your statement is actually wrong.
In addition, I think the last part "although the +none+ type has also been used" is a bit confusing.
I think we should rather:
1. Look again closely at which version control systems currently produce reproducible archives in Buildroot.
2. Make Buildroot actually check the hashes for the downloads made through those version control systems.
3. Update the documentation accordingly, with a clear statement of which packages should have hashes, which packages should not.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/1 documentation: hash source control archives
Quoted 12 lines · Thomas Petazzoni
The line needs to be wrapped to 72 characters.
Also, I am not sure that the archives we produce from all version control systems are reproducible. I'm sure it's the case for Git, but I'm not sure for Subversion, so it might be that your statement is actually wrong.
In addition, I think the last part "although the +none+ type has also been used" is a bit confusing.
I think we should rather:
Quoted 8 lines
1. Look again closely at which version control systems currently produce reproducible archives in Buildroot.
2. Make Buildroot actually check the hashes for the downloads made through those version control systems.
3. Update the documentation accordingly, with a clear statement of which packages should have hashes, which packages should not.
Okay--I think this is more than I can dive into at the moment. Either way though, this isn't currently a suitable patch so I've marked it as rejecetd in patchwork.
--Ash