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
> 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
> his devbox while being totally incompetent at putting it in an
> ebuild?

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.

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...


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