1 |
On Sun, Oct 11, 2020 at 7:35 AM Joonas Niilola <juippis@g.o> wrote: |
2 |
|
3 |
> |
4 |
> |
5 |
> On 10/11/20 4:40 PM, Thomas Deutschmann wrote: |
6 |
> > |
7 |
> > |
8 |
> > First of all, calm down. You are reading too much into this. Just |
9 |
> > revert your own logic: You obviously like your idea, worked on this |
10 |
> > and pushed it to repository. Don't you see that anyone could ask the |
11 |
> > same? Who are you? Why do believe that you can force something like |
12 |
> > that down to everyone's system? That feature got enabled in developers |
13 |
> > profiles by default, it will blow up distfiles with useless data (a |
14 |
> > view you can have when you share my concerns and don't see any |
15 |
> > problems with current Manifest system; For example we banned stuff in |
16 |
> > $FILESDIR before and asked developers to move them to d.g.o when >25kb |
17 |
> > in total arguing that large distfile is affecting *any* user... I am |
18 |
> > not comparing this 1:1 but to repeat your question: Who are you that |
19 |
> > you can decide to force something similar down to everyone). |
20 |
> > |
21 |
> > |
22 |
> > Sure, if I am the only having that opinion and most people see a value |
23 |
> > in this and disagree with me... |
24 |
> |
25 |
|
26 |
I split this into three parts: |
27 |
|
28 |
(1) Is there a problem? I like to think there is general agreement that |
29 |
developers do not cryptographically verify distfiles for most upstreams |
30 |
when bumping, and thus we could all agree there is room for improvement |
31 |
here. In an ideal world we are relying on existing systems (https, CAs, |
32 |
etc) to prevent MITM attacks on source downloads, but not much is used |
33 |
beyond that. |
34 |
(2) Does the proposed solution help? This is not a yes or no question; its |
35 |
nuanced. Having a keyring makes verifying easier. As Whissi notes, we don't |
36 |
discuss much the managing of said keyrings (or revocation) and so I think |
37 |
the proposed solution does have similar problems to the existing solution. |
38 |
Instead of managing and verifying upstream tarballs, we have to verify |
39 |
keys. There is no automation for this either...and so we end up with a |
40 |
similar attack surface. There is *improvement* (if someone MITMs your |
41 |
download, the verification will notice.) Is that the most likely attack, or |
42 |
is it stolen upstream signing keys? Who can really say? |
43 |
(3) The implementation. This is honestly the part that I dislike the most, |
44 |
particularly in the original draft, some of the problems have been fixed |
45 |
already. I'm not excited about thousands of new packages, nor am I excited |
46 |
about the key management in the proposal. The biggest problem (that it was |
47 |
on by default) were already fixed which is good; I don't even see this as a |
48 |
feature for end users at all; instead its a feature for developers and |
49 |
maybe a QA bot (that verifies the distfiles.) |
50 |
|
51 |
Leading out of 3, maybe that is a decent solution also. Can we build a QA |
52 |
bot that detects bad bumps but also has not terrible key management? Is |
53 |
there an automated protocol for fetching *and* verifying upstream files |
54 |
like this? Could we annotate SRC_URI somehow with verification metadata? |
55 |
|
56 |
-A |
57 |
|
58 |
|
59 |
|
60 |
> > |
61 |
> > |
62 |
> I vote for disabling that USE flag in developer profile. There are more |
63 |
> than 1 person using it not yet buying or understanding this "draft". I |
64 |
> also believe such a profile flag change should be discussed first. |
65 |
> |
66 |
> -- juippis |
67 |
> |
68 |
> |