Re: Changed source archive of StreamDevice release 2.8.22

[NICOLE Remi via Tech-talk <tech-talk at aps.anl.gov>]

Hello Michael,

> With epics-base, and my own projects, I'm trying to use PGP signed
> tags.
> Which can be verify independently of github.com (or any forge site).

I do think verifying PGP signatures on tags and commits is important
when packaging software, but for checking the authenticity of the
version that you are packaging. I personally think that once the
authenticity has been verified (once, by the person packaging the
software), only integrity matters for build systems.

It is true that the GitHub export archive is probably the result of
`git archive`, but because it is not documented as such, `git archive`
specific behavior should not be relied upon. But the GitHub archive has
been proven to be quite reliable in providing an archive containing the
source code. From a quick search:

- Buildroot documents the usage of GitHub archives[1], and packages
almost always use them in practice
- Yocto also documents their usage[2], and quite a few packages use
them
- Nixpkgs use them for 11'000+ packages, and I found only 3 explicitly
falling back to using Git, due to the usage of export-ignore in
.gitattributes

I have spent quite some time packaging software from GitHub, and I
think that's the first time I stumbled upon an issue with them. I
personally think they're quite reliable at what they're documented for:
being an archive of the repository.

[1]:
https://buildroot.org/downloads/manual/manual.html#github-download-url
[2]:
https://docs.yoctoproject.org/ref-manual/classes.html?highlight=github#github-releases

> imo. concerns of this sort are a good reason to avoid relying on
> github.com
> specific behavior like the automatic .tar/.zip file creation.

I'm curious to see your opinion as to why we should not be relying upon
GitHub archives. To me, the observed behavior was expected due to the
usage of `export-*` attributes, but I might have missed something.

> fyi. my primary key is 5C159E669D69E2D4C4E74E540C8E1C8347330CFB
>
https://keys.openpgp.org/vks/v1/by-fingerprint/5C159E669D69E2D4C4E74E540C8E1C8347330CFB

Thanks for you GPG key! I'll use that in the future.

> Of course, with current state of the PGP key server system, managing
> keys
> is even more of a challenge than previously...

Yeah... I'm not sure what key server is up these days either, so here's
my GPG key using GitHub (urgh...):

https://github.com/minijackson.gpg

Have a great day!
-- 
Rémi NICOLE <remi.nicole at cea.fr>
CEA/DRF/IRFU/DIS/LDISC