From ArchWiki

[edit] alternative 2 will cause confusion

i don't like the alternative 2 with interim pkgs because this may mean that there are packages comming not from the repos but from somewhere else. if the patched pkg is working and also compiling against CURRENT, i can assure you that this change will be in the repos very soon. if a developer is not around, others step in and help updating things. often there are reasons while a update or fix is waiting that the community is not aware of that the pkg maintainer knows. in most cases the problem is a pkg that is not compiling against CURRENT or causes other pkgs to break. this will be realised by the STF TU's in the end when they try to fix the pkg and test it. adding a patch or fixing a pkg always results in testing it before it is free to be used by the commuinty. if the fix is breaking othre things, this may result in chaos.

instead of alternative 2 i see only the alternative 1. announce it and show that it is fixable. if you tested it, email the pkg maintainer(s) that this pkg may be fixed with new patch or new version or in whatever way you found out to be the solution. --Dp 22:05, 29 Jul 2005 (EDT)

Hmm, well that's the reason we call it an interim pkg. Readers of arch-security would be advised that the interim pkg is not an official one. However, I understand your point and believe that alternative 2 would probably happen very seldom, if at all. In any case, for the first time we can go only with alternative 1, and see how that works out - I suppose we'll see later how to deal with busy maintainers, if we need to at all. --Maxsipos 22:51, 29 Jul 2005 (EDT)

Should we remove the alternative 2 from this STF draft document, then? --Dp 07:47, 31 Jul 2005 (EDT)

Done. Any other ideas, or shall we make the official announcement/request on the mailing list? --Maxsipos 11:54, 31 Jul 2005 (EDT)

I will ask the other devs what they thing on it. it would be easier to have some more devs behind the idea before announcing things. can you wait some days? thx--Dp 17:53, 31 Jul 2005 (EDT)

Definitely. I had no intentions of starting up anything like this without the consent of the devs.--Maxsipos 19:59, 31 Jul 2005 (EDT)

I like the idea. I've always wanted to find ways to bring together the community to get things done.

My only suggestion is to have security discussion on another mailing list instead of a forum. That way I can follow along ;o) --Xentac 18:44, 31 Jul 2005 (EDT)

This also sounds good. I wanted to keep "infrastructure" to the minimum, but if it's not a problem to get another mailing list for internal STF discussions - then great! --Maxsipos 19:59, 31 Jul 2005 (EDT)

[edit] A Security Update tool

I would like to see a tool that can handle security updates and alerts for you. In addition to emailing security updates to a mailing list, they should be stored in a database (and the email generated from this database).

Once they are in a database, a tool can be written (e.g. call it 'archsec') which can notify you of vulnerabilities on your system. I think it should have the following functionality:

With no parameters the tool should list vulnerable packages and their versions, a vulnerability 'id', a short description of the vulnerability, and the latest version available (if it fixes the vulnerability). Vulnerabilities that have no fix yet should not be ignored, they should be listed as 'unfixable'.

archsec --email-report should do the same as above, but email a report to the sysadmin, with links to the web page describing the vulnerabilities and any workarounds. The idea is to run this in a cron job.

archsec --fix-all should fix all fixable vulnerabilities on the system by upgrading the packages to non-vulnerable versions.

archsec --fix-all --exclude <pkg1> <pkg2> ... would do the same as above, but don't fix <pkg1>, <pkg2>.

archsec --fix-all --exclude <vuln id 1> <vuln id 2> ... would do the same as above, but don't fix <vuln id 1>, <vuln id 2>.

archsec --fix <pkg1> <pkg2> ... would do security updates to <pkg1>, <pkg2> if required.

archsec --fix <vuln id 1> <vuln id 2> ... would do security updates in response to particular vulnerability ids, if required.

I'd we willing to put some effort into coding this. However we should first decide how to store all this info in a database.