apt vs urpmi

Vincent Danen vdanen at linsec.ca
Wed May 3 10:46:16 PDT 2006


* Gary Greene <greeneg at phoenuxos.com> [2006-05-03 13:32:23 -0400]:

> >> Apt's media / repository handling sucks rocks really :) Some of it boils
> >> down to the sources.list format and the library for handling even that
> >> is basically non-existent, libapt-pkg only knows how to read the
> >> sources, nothing about editing it. Doing something about that is on the
> >> roadmap long-term items, the problem is that it's going to be painful
> >> wrt anything built on top of apt. For example Synaptic has it's own code
> >> to read + write sources.list entries, largely due to the shortcomings of
> >> libapt-pkg in that area.
> >
> > But this could easily enough be written in something like a shell
> > script; it doesn't need to be something apt itself.  I mean, if you
> > think about it, urpmi does all the heavy lefting of rpm installation,
> > but urpmi.addmedia and urpmi.removemedia do the media management.  True,
> > with urpmi you can tell it to disregard certain media (with the urpmi
> > --media foo option), which would be nice to see in apt, but the actual
> > adding/removing media could probably be done easy enough in a shell
> > script.
> 
> Agreed on both counts. These are the main issues being looked at by
> libapt-front being developed by Peter Rockai from RedHat and a few
> developers from other distributions, in particular Debian.

Nice.  If apt does what I need it do, and if I decide to drop urpmi for
it, I may put some effort into an elementary quick-n-dirty media handler
although having something upstream would be better, particularly for an
option like "urpmi --media foo".

> >> GPG support isn't integrated in apt but can be easily done with
> >> Lua-extensions, there are gpg-checker and gpg-autoimporter extensions
> >> included in the contrib directory of the apt tarball for example.
> >> Integrating the GPG handling again is something I'd like to do in the
> >> future.
> >
> > Ummm...  hmm.  I thought I saw support for gpg keys in the media
> > settings.  What is the point of that then?  Does apt not check if a
> > package has a proper key before doing the install?
> >
> > If not, that seriously lessens the viability of apt for me...  Annvix's
> > #1 priority is security, and integrity of rpm packages is absolutely
> > important.
> >
> > I'll have to look at these extensions to see if they'll do what is
> > needed.  If I can't make apt use keys and verify packages before
> > installation, I can't use it.
> 
> I've used apt-rpm on SuSE and they did do what you want, though I'd
> personally like to extend the scripts a little more since they currently
> do a all or nothing method of handling, such that if ANY of the packages
> are unsigned, they will not be installed at all, without any intervention
> from the administrator.

That's not necessarily a bad thing.  I'd almost prefer that.  If
something has been tampered with, I'd like a all-stop so that an admin
can look at things and see if their repository is corrupt or if
something did indeed get compromised.

But I can also see an argument for leaving out the bad package and
installing the rest.

> >> <cough> Security... <cough> I wouldn't count on that too much at the
> >> moment, apt's codebase is *dirty* but the intent is certainly to clean
> >> it up + make it safer.
> >
> > Hmmm....  well, I guess one way around that is to make apt only
> > executable by root (or via sudo).  Normal rpm queries, etc. can still be
> > done by a normal user, but install/uninstall/everything-else via apt
> > will have to be root-restricted then.
> 
> This seems to be reasonable to me, as the aspect of adding and removing
> software should only be done via a trusted account.

Right, but I'm suspecting that, while apt may not be installed suid, it
may be executable by all users.  I'd have to install it mode 700 if
there were any questions as to it's security.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}
Wasting time like it was free...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/attachments/20060503/e11b229c/attachment-0003.pgp>


More information about the Apt-Rpm mailing list