Suggestion: github releases
FYI, the 3.0.15 download doesn't seem to be working: $ lftp ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.15.tar.gz cd: Access failed: 550 /pub/freeradius/freeradius-server-3.0.15.tar.gz: No such file or directory Related, there is no release_3_0_15 tag in the github repo. Can I make a suggestion that might kill two birds with one stone? Specifically, perhaps it's worth considering using github releases for the downloads? This will enforce the tagging in the public repy, and also github will handle serving the downloads which is overall likely to be more reliable. Anyway, just a thought. Regards, Phil
On 17/07/2017 14:59, Phil Mayers wrote:
On 17/07/2017 14:57, Phil Mayers wrote:
Can I make a suggestion that might kill two birds with one stone? Specifically, perhaps it's worth considering using github releases for
Actually maybe I'm being an idiot here - there appear to be released on the public repo?
Yes I'm definitely being an idiot. Sorry all for the noise, please disregard. (I do still think the download link on the website might be better pointed at the GH release but maybe there's a reason for that?)
On Jul 17, 2017, at 9:57 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
FYI, the 3.0.15 download doesn't seem to be working:
$ lftp ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.15.tar.gz cd: Access failed: 550 /pub/freeradius/freeradius-server-3.0.15.tar.gz: No such file or directory
It works for me from all networks I have access to.
Related, there is no release_3_0_15 tag in the github repo.
I just pushed that.
Can I make a suggestion that might kill two birds with one stone? Specifically, perhaps it's worth considering using github releases for the downloads? This will enforce the tagging in the public repy, and also github will handle serving the downloads which is overall likely to be more reliable.
The issue is then the distribution isn't signed... Alan DeKok.
On 17/07/2017 15:08, Alan DeKok wrote:
It works for me from all networks I have access to.
Hmm. Ok, so wget is working for me now, but a colleague had this: $ wget ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.15.tar.bz2 --2017-07-17 14:48:30-- ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.15.tar.bz2 => `freeradius-server-3.0.15.tar.bz2' Resolving ftp.freeradius.org... 62.210.29.29 Connecting to ftp.freeradius.org|62.210.29.29|:21... connected. Logging in as anonymous ... Login incorrect. ...at about 14:49 BST. I've no idea what's going on with lftp. Sigh, never mind.
I just pushed that.
Indeed, just spotted it - many thanks.
The issue is then the distribution isn't signed...
Ah. I think it's possible to generate the GPG sig locally after the tarball has been generated (and verified of course...) and then insert it into the release, but that is a bit of a faff I guess. It's a shame there isn't some workflow here where the developer could sign a tag, then GH build a tarball of the signed tag, and sign the tarball with some kind of per-project key. Oh well.
On 17 Jul 2017, at 15:20, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Ah. I think it's possible to generate the GPG sig locally after the tarball has been generated (and verified of course...) and then insert it into the release, but that is a bit of a faff I guess.
It's a shame there isn't some workflow here where the developer could sign a tag, then GH build a tarball of the signed tag, and sign the tarball with some kind of per-project key. Oh well.
The workflow is pretty simple - you either: * create the release in draft form, download it for signing, then add the detached signature as a second binary. * create the tarball locally using git archive (which should create a bit-for-bit clone of what GitHub will serve) then sign and upload the detached signature as a second binary. Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On Jul 17, 2017, at 10:20 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Hmm. Ok, so wget is working for me now, but a colleague had this:
$ wget ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.15.tar.bz2 --2017-07-17 14:48:30-- ftp://ftp.freeradius.org/pub/freeradius/freeradius-server-3.0.15.tar.bz2 => `freeradius-server-3.0.15.tar.bz2' Resolving ftp.freeradius.org... 62.210.29.29 Connecting to ftp.freeradius.org|62.210.29.29|:21... connected. Logging in as anonymous ... Login incorrect.
...at about 14:49 BST.
Transient issues? Alan DeKok.
On 17/07/17 15:28, Alan DeKok wrote:
Transient issues?
I guess, hard to know without knowledge of the FTP infrastructure. It's working now, so no need to worry. Also I forgot to add: many thanks for doing this work, and the comprehensive writeup of the issues. It's a great reminder how tricky C is, and the effort involved by dedicated maintainers. Regards, Phil
On Jul 18, 2017, at 5:26 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
I guess, hard to know without knowledge of the FTP infrastructure. It's working now, so no need to worry.
We had the power off in our office, that may have been it. But it was weird that I could upload the tar files fine, and then people couldn't download them...
Also I forgot to add: many thanks for doing this work, and the comprehensive writeup of the issues. It's a great reminder how tricky C is, and the effort involved by dedicated maintainers.
That was two weeks of fixing code, testing, re-fixing, revising the writeup, etc. Lots and lots of effort by yours truly. :( The good news is that the code is getting better. The fixes for v3 were easier than for v2. And we're working on v4 coding styles to avoid even more of these issues. And, adding fuzzing / address sanitization to the code and automated tests. Alan DeKok.
participants (3)
-
Adam Bishop -
Alan DeKok -
Phil Mayers