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.
