Projects that use https://sourceware.org/pub/ for releases need a shell account and are responsible for providing signatures themselves (although we do generate md5 and sha512 sums). It would be good to provide a release mechanism like: https://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads So no shell access is required and signatures are.
mark at klomp dot org via Overseers <overseers@sourceware.org> writes: > https://sourceware.org/bugzilla/show_bug.cgi?id=29643 > > Bug ID: 29643 > Summary: Release upload process improvements > Product: sourceware > Version: unspecified > Status: NEW > Severity: normal > Priority: P2 > Component: Infrastructure > Assignee: overseers at sourceware dot org > Reporter: mark at klomp dot org > Target Milestone: --- > > Projects that use https://sourceware.org/pub/ for releases need a shell account > and are responsible for providing signatures themselves (although we do > generate md5 and sha512 sums). > > It would be good to provide a release mechanism like: > https://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads > So no shell access is required and signatures are. Is it better to comment on these in bugzilla? Apparently I never created one, I just emailed, in the meantime, I'll reply here. This is a great idea, and I suggest using the GNU FTP software. It is unpublished currently, I think only because of momentum that it started as a tiny script 16 years ago but we (FSF) could publish and/or share it right away (just say the word). We recently had a volunteer audit the code for security issues and have been working toward publish a release that had all the documentation for other people to easily use it, but that doesn't need to be perfect, we can just do it. Right now, I see that GCC, GDB, GLIBC and Binutils are published both places, so this seems like an obvious area for more cooperation/coordination For example, (and I would just open a separate bug for this, but I want to get this off my chest): I notice that the sort order on https://sourceware.org/pub/ is alphabetical instead of version ordering, which is confusing. On the GNU FTP, we apparently get the right sort ordering through debian's config, /etc/apache2/mods-available/autoindex.conf, the line seems to be: IndexOptions FancyIndexing VersionSort HTMLTable NameWidth=* DescriptionWidth=* Charset=UTF-8, the debian upstream repo for this config is https://salsa.debian.org/apache-team/apache2 in the path ./debian/config-dir/mods-available/autoindex.conf I suggest adding that line to the sourceware apache config.
(In reply to iank from comment #1) > This is a great idea, and I suggest using the GNU FTP software. It is > unpublished currently, I think only because of momentum that it started > as a tiny script 16 years ago but we (FSF) could publish and/or share it > right away (just say the word). We recently had a volunteer audit the > code for security issues and have been working toward publish a release > that had all the documentation for other people to easily use it, but > that doesn't need to be perfect, we can just do it. If you do publish the scripts please add a pointer in this bug. > For example, (and I would just open a separate bug for this, but I want > to get this off my chest): I notice that the sort order on > https://sourceware.org/pub/ is alphabetical instead of version ordering, > which is confusing. On the GNU FTP, we apparently get the right sort > ordering through debian's config, It looks like we already are using VersionSort so this should be correct. Do you have an directory where the sort oder is wrong?
Update: A volunteer, Jacob Bachmeyer, is working on doing some documenting and refactoring so it is reasonable for anyone to adopt and use instead of just the GNU release site. For example having a documented config file instead of hard coded variables with path locations. His estimate for this is a few weeks to a month or three, and I prefer to wait to publish it until then. But as I said before, if you want is sooner, just ask and I can provide it privately under GPLv3+ in it's current state and then of course you have the freedom to share as you wish. I will definitely add a pointer on this bug when we publish it.
Any update on publishing the scripts? If the review isn't complete yet could you sent them privately so we can inspect them ourselves and try them out on sourceware?
mark at klomp dot org via Overseers <overseers@sourceware.org> writes: > https://sourceware.org/bugzilla/show_bug.cgi?id=29643 > > --- Comment #4 from Mark Wielaard <mark at klomp dot org> --- > Any update on publishing the scripts? > > If the review isn't complete yet could you sent them privately so we can > inspect them ourselves and try them out on sourceware? Yes. Give me another day or so.
I understand this is public, we just aren't ready to advertise it yet: git clone https://vcs.fsf.org/git/gatekeeper.git
As you will see from the repo, development got stalled over the winter holiday but we are picking it back up again.