Russell Stuart <russell-deb...@stuart.id.au> writes: > If there are two "ways" and one requires a human and the other is > completely automatic, all other things being equal for me the "right" > way is the automated one. I know my limitations - not being > conscientious when doing manual repetitive labour is one of them.
That's a valid point. But I'm not sure that presence of the package in the archive is the best trigger here, particularly since there can be information in the security advisory that's rather important, such as an additional upgrade step that has to be performed. We try to avoid that, of course, but it has happened. Also, this means that you completely miss security advisories that *don't* involve changing a package in the archive, like "this thing is a disaster, so we're pulling it from the archive entirely and suggest you stop using it." This implies to me that we need some better tool than just triggering off of package availability to address these concerns. I personally think the concerns are fairly minor and the cost is not worth the benefit, but that said, I have often wished debsecan was more generally useful. Volunteering to help the security team improve it might be a good path forward for someone wanting to work in this area. > Yes, I agree. But for me apt.conf/Max-ValidTime is useless unless the > release file is guaranteed to be updated more frequently than its > "Valid-Until:" header implies. Is it, and is that undertaking > documented somewhere? Point. We should have documentation for what the minimum signing frequency we guarantee is, particularly for the security archive. Then, people who are willing to suffer from mirror issues if they're slow can just use that. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87egtqcfw9....@hope.eyrie.org
