1 |
On Sun, Feb 3, 2019 at 2:28 PM Michał Górny <mgorny@g.o> wrote: |
2 |
> |
3 |
> 1. Should the access be open or explicitly granted? If the latter, how |
4 |
> should we determine whether to grant access for a particular |
5 |
> contributor? |
6 |
> |
7 |
|
8 |
Obviously we're going for a low barrier to entry here. However, I |
9 |
think there needs to be SOME kind of reputation system in place (not |
10 |
necessarily at time of account creation) otherwise we're going to be |
11 |
open to completely trivial attacks. |
12 |
|
13 |
One thing I don't like about AUR is that fairly non-exotic packages |
14 |
end up residing there solely, and updating these becomes tedious, |
15 |
because you basically have to protect yourself against the script |
16 |
kiddies. I don't think our intent here is to have the main repository |
17 |
focus mainly on @system though, so this might not be as much of an |
18 |
issue. |
19 |
|
20 |
We probably do need to have some way to keep users from just shooting |
21 |
themselves in the foot. Unless we have a really strong vetting |
22 |
process for packages in this alternate repository we're not going to |
23 |
want to have people just blindingly accepting updates from there. All |
24 |
that said I think the "AUR Helper" approach Arch uses is a pretty |
25 |
clunky approach. |
26 |
|
27 |
I feel like there ought to be some kind of reputation-based solution |
28 |
where users can earn karma based on actual contributions and then for |
29 |
updates to be eligible for keywording or whatever they have to be |
30 |
endorsed by users with enough collective karma or something. |
31 |
Obviously that is way less trivial to build than a random git repo |
32 |
that lots of people can push to or whatever. |
33 |
|
34 |
If we had a reputation-based system then anybody could be allowed to |
35 |
submit ebuilds without any vetting, since they wouldn't actually |
36 |
become keyworded/effective/published/whatever until they get vouched |
37 |
for. However, we'd have to avoid a system where account spam can be |
38 |
used to play karma games quickly and sneak in packages. |
39 |
|
40 |
Another approach would be a WoT-like system where users pick what |
41 |
other users THEY trust and the package manager understands this, so |
42 |
only ebuilds endorsed by that other user are accepted. Maybe like GPG |
43 |
there can be trust levels/scores so that more than one endorsement is |
44 |
allowed. Being end-user-driven this would be much less susceptible to |
45 |
karma games. It probably would require a lot less micromanagement as |
46 |
well and there are no longer arguments over who should/shouldn't get |
47 |
karma as every end user gets to decide for themselves. On the flip |
48 |
side it does let users shoot themselves in the foot, which I guess is |
49 |
how we tend to roll here... |
50 |
|
51 |
Really, though, you have to expect that something like this is going |
52 |
to get abused. I think the key is to make abuse non-trivial so that |
53 |
we aren't playing whack-a-mole with rootkit installers. |
54 |
|
55 |
-- |
56 |
Rich |