[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

checking apt repositories for glitches

On Sun, 2011-09-04 at 12:47 +0200, David Kalnischkies wrote:

> Beside that repositories really should provide checksums and
> signatures for security reasons[0]
> Users should take that as an open invitation to bug repository admins
> to "fix" their repositories. Most of these seem to be created by complicated
> hand-made scripts and could be replaced by a shorter and better-working
> 'apt-ftparchive generate' (at least that was the case for a fellow student).
> Feel free to ask on deity@l.d.o or in #debian-apt for help (but prepare for
> non-immediate response) - or refer to one of the debian-user lists if you
> can't work out how to set it up from the manpages/examples.

For the Debian derivatives census I've been writing some scripts to
validate apt repositories. So far I just have one that checks the
Packages and Sources files for missing hashes. I'd like to do more
checks but am not sure what else can go wrong with apt repositories. I'm
hoping the apt developers have more experience with this and can suggest
some more checks I could do.

I also want to validate sources.list files (for eg to check for deb-src
entries for each deb entry). I'm interested if there are common mistakes
I could check for in that too. I also need to write a minimal parser in
python before I can do this.

> [0] It's kind of pointless to get excited about a kernel.org break-in
> if every user of repository X is forced to trust that not a single system
> on the way between his computer and the repository is compromised.
> See man-in-the-middle attacks for a start on this topic.

On that note, it would be nice to have a way to disable running
maintainer scripts as root for less trusted archives. I guess replacing
the apt sources.list format would be a blocker for this though.



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

Reply to: