Re: Thoughts on APT architecture and hardening
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, 2019-01-24 at 16:50 +0100, David Kalnischkies wrote:
Hi David, thanks for the lengthy response.
> On Wed, Jan 23, 2019 at 10:58:15AM +0100, Yves-Alexis Perez wrote:
> > I didn't really know about apt architecture and the fact that fetchers are
> > forked. I think it's a good idea to isolate exposed workers dealing with
> > untrusted data (especially HTTP), but apt main process seems to trust data
> > coming from the workers. I'm unsure where is the boundary trust here, but
> if
> > the fetchers data is trusted, I guess workers shouldn't just copy content
> from
> > outside to inside but do a real (/complex) sanitation job before handling
> it
> > to apt?
>
> This architecture is allowed to drink beer in basically every country in
> the world by now (aka: older than 21 years)
Quick note here: I don't think it's by itself a good or bad indicator. There
are 21-year old ideas we really need to throw away, and there are also a lot
of things which have been solved in the pass and we don't need to reinvent it
(badly).
>
> > As I understand it, the file hashes are calculated (or in this case,
> injected
> > from outside) by the worker, and not by the apt main process. Is that a
> good
> > idea?
>
> So yes, we fully trust the method to behave nicely. It is rather hard to
> change that (see e.g. store – the potential compressed files it produces
> can't be verified) and in many ways I don't think it would be a good
> idea. It actually helps that a method can do basically everything as
> that allowed us to introduce things like _apt in the methods, it
> wouldn't have been possible to do it in the main process if we came at
> it with a "don't trust the methods" attitude.
I'm not criticizing the split between methods and apt, quite the contrary. I'm
just surprised that apt trust the output from the method (especially since
they're exposed to the outside).
>
> In the end I don't think this (or any previous) security bug is
> inherently due to this or that architecture and we would have no
> security bugs if only we would have this or that other architecture.
> If there is a pattern in the last few security bugs than that git blame
> identifies me, but after being around for so/too long I guess that is to
> be expected and hopefully not an architectural design flaw in me… ;)
I have trouble parsing the end of this sentence.
>
> So, yeah, I know, the mob is out there and demands blood, but I don't
> think we have to rush into any drastic changes here. We have a track
> record of slow but steady evolution and I am pretty sure that will be
> the best approach again.
Just in case my initial mail was badly received, I'm sorry. I'm definitely not
part of the mob, and I quite appreciate the job you do (and Julian job during
the embargo was especially nice, considering the urgency).
>
>
> Far more than clever ideas, endless rehashing reddit/hackernews/whatever
> threads and the "https probably solves world hunger, too" mob we will
> eventually need new contributors in apt (and for that matter many other
> teams). It is a bit sad that even through I am looking at contributing
> to APT for an entire decade in May, I am still the newest addition to
> the team… (if an optimistically counted trio can still be called a team)
Yeah, the security team can definitely understand that feeling.
Regards,
- --
Yves-Alexis
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlxKF6kACgkQ3rYcyPpX
RFv5awgA6O2+FkcmZRxdCGoU3L9dXs+V05iAaOfKBVFMNUvsLLSnwiFAvhXVvUTZ
zfiX0hSP1hayx1gfZyXr3TuzcIctUTkLZhX6w/zdEimLegkGaNXIb9waOXGl/wKW
ARdtiGsu9cW1iL+tXXdcLlTHxloi4jb67IqQSQp37A1di4vc7LJC7gTawBLsMiW+
wWi3KjxujVh/6BpMBwCIuOB+smU9GKimFwnDYVxo4GLwxLzG0KCI12chfOt3ezKk
i0jHrbPTUEwOeod+9ecyFtC7aaObVTYpWEyRyOw0sr9gRtJhriIJzxX2EL2+6wz+
WO6oJNJ+oUhl/SrVpWm9kERdjjkfbw==
=qOMH
-----END PGP SIGNATURE-----
Reply to: