You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the two topics of signatures and checksums (#214) are in effect related, since the signature is nothing else than an alternative channel to receive a hash/checksum (nominally sha1) of the file in question.
### checksum: to fetch and check distribution file(s)
KH: nothing like this there yet, but there will be soon (see [1st-EasyBuild-hackathon---meeting-minutes-day-1]), so we'll use checksum for that
FG: this does not have to be ready before v1.0 but we should put a placeholder just to make it clear we have it in mind; one way to prepare well for it would be, to state sha1 checksums inside easybuild_ebfiles_repo auto-produced files; that would allow for an easy massive regression test with the pkg2eb provided package list (>600 successful targets) and if that works fine, it's green light.
Of course, trully validating the authenticity of the signatures is a whole different story.
An implementation of this idea seems to live within pacman/archlinux: https://wiki.archlinux.org/index.php/Pacman-key
I suggest we postpone this matter for post v1 (v1.1 you've picked is a good target) just make sure they are possible and the current design does not miss a potential feature!
Some packages have a .sig file, e.g. gcc
ftp://ftp.gnu.org/gnu/gcc/gcc-4.4.4/
we should check the signature, and compare the key with a trusted one.
The text was updated successfully, but these errors were encountered: