Re: [GNU-linux-libre] [gnu.org #1262331] (inactive Linux distributions)

[Ivan Zaigralin]

I really like all of these suggestions, and with respect to the security 
standard to meet, I feel that maintainers should do at least so much: publish 
(prominently!) the list of known and reported vulnerabilities which won't be 
fixed, and the reasons for not fixing them. If they can make a technical case 
for it to convince the users, great. And if they just write "not enough 
resources", again, I think users will get the correct message.

On Thursday, January 18, 2018 01:20:45 Julie Marchant wrote:
> On 2018年01月17日 16:32, Jason Self wrote:
> > That's already a thing: One of the criteria in the GNU FSDG is that "to
> > be listed, a distribution should be actively maintained." When this has
> > come up in the past, the determination of being actively maintained was
> > said to rest with the distro maintainers and if *they* consider it to be
> > maintained or not (as opposed to, say, moving slowly.)
> 
> I think it would be a good idea for a well-defined standard to be
> defined regarding whether a distro is current and maintained or not. I
> agree that distros that don't get updated often shouldn't be excluded
> from consideration, but something should be in place to ensure that the
> distro's developer(s) is (are) still involved in the project. I think
> security and compatibility implications should be considered, too; after
> all, kernels stop working with new hardware and security vulnerabilities
> happen. It wouldn't be very nice for someone to use BLAG based on the
> FSF's recommendation, only to have their credit card information stolen
> because of some old security vulnerability, or something.
> 
> I'd like to suggest the following rules as a rough draft:
> 
> 1. The distro's maintainers should annually do one of the following: (a)
> publish a new release; (b) publish a post summarizing work done on the
> distro in the prior year which directly impacts the distros users (for
> example, such a post could note important packages which have been
> updated in the current release and what these updates mean to the
> users); (c) write to the FSF to explain why no updates have been
> necessary in the respective year (and, in particular, why the security
> and hardware compatibility implications of this are unimportant).
> 
> 2. The distro should ensure one of the following: (a) that all known
> security vulnerabilities are fixed for users of the current release of
> the distro in a reasonable timeframe; (b) that new, non-technical users
> of the distro can see that it has or may have security vulnerabilities,
> e.g. via a warning on the distro's website that security updates are not
> always delivered.
> 
> 3. The distro should either: (a) be reasonably expected to be compatible
> with computers that can currently be bought from mainstream retailers;
> (b) indicate on its website what hardware it is compatible with.
> 
> So, let's go through some of the distros and how they would be affected
> by these rules:
> 
> * Trisquel, gNewSense, Dragora, GuixSD, PureOS, Parabola, and LibreCMC
> would be mostly unaffected. Those that release less often than once a
> year (e.g. Trisquel) would simply have to make annual posts summarizing
> package updates to the current release. They don't need to talk about
> all of it, just what the maintainers feel is significant. They can even
> just make a quick, non-exhaustive list of packages that have been
> updated if they want.
> 
> * BLAG would either have to get moving or fail the test. There haven't
> been any updates to the "current" release for users, BLAG 140k, in
> years, and the system is do doubt susceptible to multiple known security
> vulnerabilities. It would likely end up removed.
> 
> * Dynebolic and Musix: the respective distro's maintainer would likely
> send an email to the FSF every year noting that the lack of updates is
> intentional and add a notice to the download page that it is not a
> secure distro and should not be used to send sensitive information over
> the Internet. It's meant for media editing and secondarily local jobs
> like partitioning, so this would be easily justified. Alternatively, if
> the maintainer has lost interest in maintaining the distro, it would end
> up removed.
> 
> --
> Julie Marchant
> https://onpon4.github.io
> 
> Protect your emails with GnuPG:
> https://emailselfdefense.fsf.org

signature.asc
Description: This is a digitally signed message part.