Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs

[Thomas Deutschmann]

On 2020-10-10 22:36, Michał Górny wrote:

On Sat, 2020-10-10 at 22:10 +0200, Thomas Deutschmann wrote:

Another example for something that was not thought to the end and
which was rushed and pushed to our users.

You start this mail with an insult to me.  Why do you keep doing
this? Do you feel that there is some special need for you to try to
diminish me in order to reach your goal?

You seem to be obsessed with the idea that I am your perfect enemy... I cannot help you with that.

The whole idea started with assumption that not every developer
will verify the distfile (an assumption I share). But why should we
trust these developers that they will keep an eye on upstream’s
used certificate instead? That does not make any sense for me.

This sounds like 'perfect is the enemy of good'.  If we can't get
this done perfectly good, we should just lie down and do not put any
effort into making things better.

Sort of.

Another point I just want to mention was patch 5 of 6 for net-libs/miniupnpc. Did you notice that the ebuild will fetch

public key via HTTP instead of HTTPS?

Is this question to me or to the public?  Because if it's to me,
then yes, I've noticed I couldn't use HTTPS there.  I'm sorry, I'm
not as incompetent as you'd repeatedly trying to prove, you won't win
your argument this way.

See the first paragraph. I really don't understand why you believe I want to show world how incompetent anyone is. I am very sure that people active in Gentoo know very well that you are *not* incompetent. I am just showing a design flaw without any judgement. This is a technical mailing list. It should be possible to focus on technical aspects. One way to respond to that would maybe a discussion how we can do that better (see robbat2 mail for example). I am fully aware that this is still a draft, which is also part of my problem but I will address that later.

This will create a chicken-egg problem here: We will record key
information metadata the same way we store information about
distfiles which is temper proofed. But because this is happening in
an automatic way there is not just a theoretical chance that we
will store an attacker’s key in our metadata because who is going

to verify they key? The same developer we distrust (or where we just want to avoid to trust) that he/she verified the distfile?

What's the alternative?  Ignoring upstream signatures entirely unless

his devbox while being totally incompetent at putting it in an
ebuild?

we can securely fetch the key? Shoving the problem under the carpet and assuming that the developer will have safely set up the key on

My point here is:

You had the idea to improve something. Which is good. Improvement is always appreciated. But it must be an improvement. I expect that during the process, "Hey, I think we can do X better... what do you think about doing it that way... which will address problem Z..." we are all open minded. That means that if we come to the conclusion that something isn't really an improvement or so minor that the complexity and everything belongs to that isn't worth it, that we all realize, "OK, didn't work as expected. Withdraw the idea (maybe just until we find a better way) and move on".

Theories are all nice but do you have any proof of that?  Preferably
one that involves developers who *actually carefully* checked
distfiles. Because my theory says developers don't have infinite time
to audit everything.

I don't think I need a proof for that. I am just picking up your initial argument for this new eclass saying "I don't want to need to trust developer that distfile was checked carefully, if we would add automatism we wouldn't need to trust..." (something I share). I hoped I would have shown everyone that in the end we are only *moving* that trust we don't want to give developers that they carefully checked distfiles to keys. In other words: We haven't changed anything -- we gained nothing. We still have to trust developers that they carefully check something, now just keys instead of distfiles. The previous 'problem' this eclass wanted to improve (solve?) is still there. ...and from my POV we got an additional problem because we now have a system which will tell user, "No... distfile looks good, signature is fine" which weighs the user in a false sense of security (even Google had to learn that when they replaced padlock with "Secure" in browsers -- suddenly users stopped using their own brain because they trusted system too much which was telling them that the site which looks like their bank but wasn't their bank's site was secure). Not to mention when this system will force users to connect to arbitrary key servers...

Are you arguing that we should remove commit signatures as well? Or does it happen that with roughly the same technology and the same people, one layer is secure and another similar layer is totally bonkers?

No. First you need to understand Gentoo's threat model. Once you understand why we are using signatures you need to understand the boundaries (limits) of signatures. The way how we are using signatures is for example different because we are operating our own key infrastructure and revocation process, we aren't affected by the previous outlined issues.

The purpose of this email is to get this addition removed ASAP.

Why do you claim to have the power to removed somebody's work just because it doesn't fit your view of the world?

I am gonna merge this with my answer to first paragraph.












--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

First of all, calm down. You are reading too much into this. Just revert your own logic: You obviously like your idea, worked on this and pushed it to repository. Don't you see that anyone could ask the same? Who are you? Why do believe that you can force something like that down to everyone's system? That feature got enabled in developers profiles by default, it will blow up distfiles with useless data (a view you can have when you share my concerns and don't see any problems with current Manifest system; For example we banned stuff in $FILESDIR before and asked developers to move them to d.g.o when >25kb in total arguing that large distfile is affecting *any* user... I am not comparing this 1:1 but to repeat your question: Who are you that you can decide to force something similar down to everyone). Of course I don't have any power to remove somebody's work (and I am still wondering why you assume I have), but you obviously had the power to just push your 'idea' which is still a draft to everyone and also forces everyone to participate in your beta testing... I hope to get a majority decision on that topic with the result to kill it unless it will add any significant improvement we all want. From my point of view the current implementation is only creating security problems due to giving anyone a false sense of security and ultimately resources are wasted by everyone because there is no benefit. Sure, if I am the only having that opinion and most people see a value in this and disagree with me...

OpenPGP_signature
Description: OpenPGP digital signature