* [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
@ 2019-02-03 19:28 Michał Górny
2019-02-03 21:29 ` Kristian Fiskerstrand
` (5 more replies)
0 siblings, 6 replies; 24+ messages in thread
From: Michał Górny @ 2019-02-03 19:28 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 4217 bytes --]
Hello,
I'd like to collect feedback on starting a new project focused
on providing a platform to users work on ebuilds without the explicit
need for developer intervention.
Why?
----
The current contribution platforms seem inadequate to the needs of our
users. In particular:
- Submissions via Bugzilla etc. are inconvenient for anyone to use,
and basically rely on some developer taking them up and transferring
to ::gentoo.
- Proxy-maint requires a lot of effort for both contributors
and developers. We're undermanned for quite some time and can't handle
all the contributions timely. Plus, not every contributor wants to
become package maintainer.
- User repositories are cheap to create but cause ebuilds to be
scattered all over the place. In the end, they're inconvenient to
users, and adding them and cleaning up unmaintained repos afterwards
costs me a lot of effort.
While all of those venues have their use case, we seem to lack something
akin Arch Linux's AUR. What I'm specifically aiming for here is
a single place where users can maintain (or not) packages themselves
without unnecessary developer intervention. Something like Sunrise,
except without reviews.
What do I propose?
------------------
GURU would be an official repository maintained entirely by Gentoo
users. I'm thinking of Wiki-like workflow where anyone is allowed to
add new ebuilds or modify existing ebuilds, and users are expected to
keep order. Gentoo developers would be allowed to contribute
on the same terms as users; official developer intervention would be
only used to resolve conflicts and other kinds of trouble.
Open issues
-----------
1. Should the access be open or explicitly granted? If the latter, how
should we determine whether to grant access for a particular
contributor?
2. Where should it be hosted? Gentoo Infra is unsuitable for open
access, as we would have to add all keys manually. GitHub, GitLab, etc.
are all options.
3. How far should Gentoo policies apply? I think we should enforce
sign-off per copyright policy but let users resolve issues beyond that.
4. Should it be purely for new packages, or should forking Gentoo
packages be allowed? I'm thinking allowing forks for unmaintained
or severely outdated Gentoo packages makes sense.
5. And most importantly, what should the last 'U' stand for? My initial
idea was 'Unreviewed' but I'm open to better-sounding ideas.
Foreseen Q&A
------------
* Will it replace proxy-maint?
No, proxy-maint will continue working as-is. I expect some contributors
may switch over, and some will simply submit ebuilds both ways.
Ideally, GURU may serve as initial ebuild improvement/proofreading
exercise before moving to ::gentoo.
* Why not revive Sunrise instead?
The problem with Sunrise is that it needs active developers. Given that
it died pretty much because people lost interest, I don't think trying
to artificially revive it is going to help. Instead, I'd like to try
something new and see how it works.
* Who will be allowed to commit?
The idea is that everybody will be allowed to commit. I'm not planning
to enforce strong maintainer boundaries like in Gentoo. However,
in the end I expect the people actually working on GURU to decide
and establish best practices themselves.
* What if somebody submits malware?
This risk is inevitable. Hopefully, the Wiki-like workflow will
eventually create some kind of mutual review of new commits, and users
will look out for suspicious ebuilds. Users will be able to revert them
themselves, and developers will block reported accounts if necessary.
That said, please remember that no other way of submitting ebuilds is
free of this risk. Believe me, we don't really review the code of every
submitted package, and if somebody wrote a program with malicious
functionality and wanted to package it, it will probably be accepted.
* What if somebody misbehaves?
I think we will reserve the right to ban contributors who repeatedly
misbehave (e.g. remove packages, commit offensive stuff, etc.).
---
What do you think?
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-03 19:28 [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed] Michał Górny
@ 2019-02-03 21:29 ` Kristian Fiskerstrand
2019-02-04 5:45 ` Michał Górny
2019-02-03 22:37 ` Michael Orlitzky
` (4 subsequent siblings)
5 siblings, 1 reply; 24+ messages in thread
From: Kristian Fiskerstrand @ 2019-02-03 21:29 UTC (permalink / raw
To: gentoo-project, Michał Górny
[-- Attachment #1.1: Type: text/plain, Size: 427 bytes --]
On 2/3/19 8:28 PM, Michał Górny wrote:
> Hello,
>
> I'd like to collect feedback on starting a new project focused
> on providing a platform to users work on ebuilds without the explicit
> need for developer intervention.
What does this add over existing overlays?
--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-03 19:28 [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed] Michał Górny
2019-02-03 21:29 ` Kristian Fiskerstrand
@ 2019-02-03 22:37 ` Michael Orlitzky
2019-02-03 23:08 ` Kristian Fiskerstrand
2019-02-04 10:58 ` Alexis Ballier
` (3 subsequent siblings)
5 siblings, 1 reply; 24+ messages in thread
From: Michael Orlitzky @ 2019-02-03 22:37 UTC (permalink / raw
To: gentoo-project
On 2/3/19 2:28 PM, Michał Górny wrote:
>
> What do you think?
>
I'd like to give two conflicting answers, and maybe answer Kristian's
question as well.
Answer 1:
Every day we hear about some ridiculous security problem with the other
repositories of this type (Google's Play store, the NPM repository,
etc.) These are all an embarrassment to the organizations that run them
because the fact that their names are attached to the repository is an
implicit endorsement of its content.
Putting the "Gentoo" name on this is a bad idea. No matter how you dress
it up, this repository will be a collection of dangerous code uploaded
by complete strangers that our users will download and run as root. That
fact is not obvious to everyone, and we do a disservice to them by
hand-waving away the reality of the matter.
Answer 2:
Despite how stupid it is, people do this already. The only difference
is, right now they download untrusted code from a hundred different
strangers in ten different overlays to accomplish the same thing.
Putting these ebuilds all in one "official" overlay would prevent people
from duplicating effort, and provide a central place for junk ebuilds to
mature without the developer bottleneck getting in the way. Perhaps it
will even spur collaboration, and encourage people to read the devmanual
because those skills can immediately be put to use.
For a long time, I've wanted a third level of stability:
a) Stable
b) Unstable
c) I'm an idiot, break my system
Having the third option lets you get things out the door and into the
hands of users who are able to test them (after acknowledging the risks)
much faster. I guess this repository fills a similar void.
But, we need some sort of oversight or keyword control. Otherwise, if
everything is ~arch, some asshole is going to create a new account every
day and submit a hacked -r28976 of something in @system that will
immediately be installed on everyone's machines. Maybe this motivates
adding stability level (c) after all, for the user repo? And then it
would be available to developers as well. Food for thought.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-03 22:37 ` Michael Orlitzky
@ 2019-02-03 23:08 ` Kristian Fiskerstrand
0 siblings, 0 replies; 24+ messages in thread
From: Kristian Fiskerstrand @ 2019-02-03 23:08 UTC (permalink / raw
To: gentoo-project, Michael Orlitzky
[-- Attachment #1.1: Type: text/plain, Size: 483 bytes --]
On 2/3/19 11:37 PM, Michael Orlitzky wrote:
>>
>
> I'd like to give two conflicting answers, and maybe answer Kristian's
> question as well.
Thanks for trying, I still have a bad feeling about this. It seems like
this can be handled within existing layman infrastructure outside of
Gentoo namespace if someone cares for it.
--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-03 21:29 ` Kristian Fiskerstrand
@ 2019-02-04 5:45 ` Michał Górny
0 siblings, 0 replies; 24+ messages in thread
From: Michał Górny @ 2019-02-04 5:45 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]
On Sun, 2019-02-03 at 22:29 +0100, Kristian Fiskerstrand wrote:
> On 2/3/19 8:28 PM, Michał Górny wrote:
> > Hello,
> >
> > I'd like to collect feedback on starting a new project focused
> > on providing a platform to users work on ebuilds without the explicit
> > need for developer intervention.
>
>
> What does this add over existing overlays?
A single place where everyone is encouraged to work together, rather
than separately. Not only dump ebuilds you've written but have them
reviewed and improved by others.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-03 19:28 [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed] Michał Górny
2019-02-03 21:29 ` Kristian Fiskerstrand
2019-02-03 22:37 ` Michael Orlitzky
@ 2019-02-04 10:58 ` Alexis Ballier
2019-02-04 13:28 ` Michał Górny
2019-02-04 14:28 ` Virgil Dupras
` (2 subsequent siblings)
5 siblings, 1 reply; 24+ messages in thread
From: Alexis Ballier @ 2019-02-04 10:58 UTC (permalink / raw
To: gentoo-project
On Sun, 03 Feb 2019 20:28:49 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> ---
> What do you think?
>
What is the difference with sunrise ?
One of the advantages of sunrise is that it had 2 repos: One
unreviewed, without Gentoo official name and big fat warnings, one
reviewed by devs more widely available.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 10:58 ` Alexis Ballier
@ 2019-02-04 13:28 ` Michał Górny
2019-02-04 13:43 ` Brian Evans
2019-02-04 13:48 ` Alexis Ballier
0 siblings, 2 replies; 24+ messages in thread
From: Michał Górny @ 2019-02-04 13:28 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]
On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote:
> On Sun, 03 Feb 2019 20:28:49 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > ---
> > What do you think?
> >
>
> What is the difference with sunrise ?
The difference, as noted in the mail, is that it doesn't rely
on developers having time to review ebuilds. Therefore, it is less
likely to die because of developers lacking time to review stuff.
> One of the advantages of sunrise is that it had 2 repos: One
> unreviewed, without Gentoo official name and big fat warnings, one
> reviewed by devs more widely available.
No.
First of all, they weren't really two repos -- they were more like
private and public branches which were made into two repos due to
technical limitations. With the public branch getting all the commits
from private branch merged.
Secondly, both branches were reviewed. The difference is that people
were supposed to ask for (IRC) review before committing to the first
branch, and only developers were allowed to merge to the second branch.
Thirdly, I have no clue what 'Gentoo official name' is in this contexts
and I certainly don't recall big fat warnings. The only difference was
that the public repo was advertised publicly while the former was
intended for development.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 13:28 ` Michał Górny
@ 2019-02-04 13:43 ` Brian Evans
2019-02-04 14:02 ` Michał Górny
2019-02-04 13:48 ` Alexis Ballier
1 sibling, 1 reply; 24+ messages in thread
From: Brian Evans @ 2019-02-04 13:43 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1.1: Type: text/plain, Size: 914 bytes --]
On 2/4/2019 8:28 AM, Michał Górny wrote:
> On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote:
>> On Sun, 03 Feb 2019 20:28:49 +0100
>> Michał Górny <mgorny@gentoo.org> wrote:
>>
>>> ---
>>> What do you think?
>>>
>>
>> What is the difference with sunrise ?
>
> The difference, as noted in the mail, is that it doesn't rely
> on developers having time to review ebuilds. Therefore, it is less
> likely to die because of developers lacking time to review stuff.
It's a horrible thing not to have reviewed builds. They can be
increasingly bad quality. Even going as far as ignoring PMS or
redefining every variable because they don't like things (yes, we've
seen this in recent times).
We have Gentoo developers for a reason and that should not change.
Blindly accepting community contributions is a dangerous game.
This just feels like a train wreck in the making.
Brian
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 13:28 ` Michał Górny
2019-02-04 13:43 ` Brian Evans
@ 2019-02-04 13:48 ` Alexis Ballier
2019-02-04 13:54 ` Michał Górny
1 sibling, 1 reply; 24+ messages in thread
From: Alexis Ballier @ 2019-02-04 13:48 UTC (permalink / raw
To: gentoo-project
On Mon, 04 Feb 2019 14:28:28 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote:
> > On Sun, 03 Feb 2019 20:28:49 +0100
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> > > ---
> > > What do you think?
> > >
> >
> > What is the difference with sunrise ?
>
> The difference, as noted in the mail, is that it doesn't rely
> on developers having time to review ebuilds. Therefore, it is less
> likely to die because of developers lacking time to review stuff.
Then I fear you will see the same pitfalls, and it already started: I
recall sunrise haters being very strongly against the idea because,
TBH, our sandboxing mechanism isn't a real sandbox. It may have
improved, but I doubt it's up to the point that we can safely run
untrusted code there.
>
> > One of the advantages of sunrise is that it had 2 repos: One
> > unreviewed, without Gentoo official name and big fat warnings, one
> > reviewed by devs more widely available.
>
> No.
>
> First of all, they weren't really two repos -- they were more like
> private and public branches which were made into two repos due to
> technical limitations. With the public branch getting all the commits
> from private branch merged.
Yeah, that's the same idea but modernized.
> Secondly, both branches were reviewed. The difference is that people
> were supposed to ask for (IRC) review before committing to the first
> branch, and only developers were allowed to merge to the second
> branch.
That's also the same idea to me.
> Thirdly, I have no clue what 'Gentoo official name' is in this
> contexts and I certainly don't recall big fat warnings. The only
> difference was that the public repo was advertised publicly while the
> former was intended for development.
It was officially strongly discouraged to use the non dev-merged
branch. That is what I would call a big fat warning.
Don't get me wrong: I like the idea. Just making sure not to repeat past
mistakes.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 13:48 ` Alexis Ballier
@ 2019-02-04 13:54 ` Michał Górny
2019-02-04 14:04 ` Alexis Ballier
0 siblings, 1 reply; 24+ messages in thread
From: Michał Górny @ 2019-02-04 13:54 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]
On Mon, 2019-02-04 at 14:48 +0100, Alexis Ballier wrote:
> On Mon, 04 Feb 2019 14:28:28 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote:
> > > On Sun, 03 Feb 2019 20:28:49 +0100
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > >
> > > > ---
> > > > What do you think?
> > > >
> > >
> > > What is the difference with sunrise ?
> >
> > The difference, as noted in the mail, is that it doesn't rely
> > on developers having time to review ebuilds. Therefore, it is less
> > likely to die because of developers lacking time to review stuff.
>
>
> Then I fear you will see the same pitfalls, and it already started: I
> recall sunrise haters being very strongly against the idea because,
> TBH, our sandboxing mechanism isn't a real sandbox. It may have
> improved, but I doubt it's up to the point that we can safely run
> untrusted code there.
Sandboxing has nothing to do with security, and trying to 'improve' its
security is a waste of time. What's the point of preventing ebuilds
from doing malicious things at build time if they can install files that
do malicious things afterwards?
>
>
> >
> > > One of the advantages of sunrise is that it had 2 repos: One
> > > unreviewed, without Gentoo official name and big fat warnings, one
> > > reviewed by devs more widely available.
> >
> > No.
> >
> > First of all, they weren't really two repos -- they were more like
> > private and public branches which were made into two repos due to
> > technical limitations. With the public branch getting all the commits
> > from private branch merged.
>
>
> Yeah, that's the same idea but modernized.
>
>
> > Secondly, both branches were reviewed. The difference is that people
> > were supposed to ask for (IRC) review before committing to the first
> > branch, and only developers were allowed to merge to the second
> > branch.
>
> That's also the same idea to me.
I was correcting your mistakes about Sunrise, not describing GURU.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 13:43 ` Brian Evans
@ 2019-02-04 14:02 ` Michał Górny
2019-02-04 14:25 ` Michael Orlitzky
0 siblings, 1 reply; 24+ messages in thread
From: Michał Górny @ 2019-02-04 14:02 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]
On Mon, 2019-02-04 at 08:43 -0500, Brian Evans wrote:
> On 2/4/2019 8:28 AM, Michał Górny wrote:
> > On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote:
> > > On Sun, 03 Feb 2019 20:28:49 +0100
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > >
> > > > ---
> > > > What do you think?
> > > >
> > >
> > > What is the difference with sunrise ?
> >
> > The difference, as noted in the mail, is that it doesn't rely
> > on developers having time to review ebuilds. Therefore, it is less
> > likely to die because of developers lacking time to review stuff.
>
> It's a horrible thing not to have reviewed builds. They can be
> increasingly bad quality. Even going as far as ignoring PMS or
> redefining every variable because they don't like things (yes, we've
> seen this in recent times).
That's inevitable. 'Horribly bad quality' happens in Gentoo as well,
more often than you think. The difference is, people throw mud at you
on public mailing lists if you dare point it out to them.
The question is: is the effort needed to review everything justified?
Let's say you have two repositories: one where everything is reviewed
(and people can commit only after getting approval), and the other where
it's not (and people can commit at any time, and others can improve
their ebuilds). You let them run like this for 6 months. Do you think
the number of good quality ebuilds in repository A will be significantly
greater than number of good quality ebuilds in repository B?
> We have Gentoo developers for a reason and that should not change.
> Blindly accepting community contributions is a dangerous game.
What is that reason? How is 'blindly accepting community contributions'
different from 'blindly accepting new developers'? In the former case,
at least we're not pretending things are secure when they're not.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 13:54 ` Michał Górny
@ 2019-02-04 14:04 ` Alexis Ballier
2019-02-04 14:13 ` Michał Górny
0 siblings, 1 reply; 24+ messages in thread
From: Alexis Ballier @ 2019-02-04 14:04 UTC (permalink / raw
To: gentoo-project
On Mon, 04 Feb 2019 14:54:40 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> On Mon, 2019-02-04 at 14:48 +0100, Alexis Ballier wrote:
> > On Mon, 04 Feb 2019 14:28:28 +0100
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> > > On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote:
> > > > On Sun, 03 Feb 2019 20:28:49 +0100
> > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > >
> > > > > ---
> > > > > What do you think?
> > > > >
> > > >
> > > > What is the difference with sunrise ?
> > >
> > > The difference, as noted in the mail, is that it doesn't rely
> > > on developers having time to review ebuilds. Therefore, it is
> > > less likely to die because of developers lacking time to review
> > > stuff.
> >
> >
> > Then I fear you will see the same pitfalls, and it already started:
> > I recall sunrise haters being very strongly against the idea
> > because, TBH, our sandboxing mechanism isn't a real sandbox. It may
> > have improved, but I doubt it's up to the point that we can safely
> > run untrusted code there.
>
> Sandboxing has nothing to do with security, and trying to 'improve'
> its security is a waste of time. What's the point of preventing
> ebuilds from doing malicious things at build time if they can install
> files that do malicious things afterwards?
Because one may or may not run a malicious binary. You are more likely
to install it. And even more likely to source the ebuild.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 14:04 ` Alexis Ballier
@ 2019-02-04 14:13 ` Michał Górny
2019-02-04 14:35 ` Alexis Ballier
0 siblings, 1 reply; 24+ messages in thread
From: Michał Górny @ 2019-02-04 14:13 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]
On Mon, 2019-02-04 at 15:04 +0100, Alexis Ballier wrote:
> On Mon, 04 Feb 2019 14:54:40 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > On Mon, 2019-02-04 at 14:48 +0100, Alexis Ballier wrote:
> > > On Mon, 04 Feb 2019 14:28:28 +0100
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > >
> > > > On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote:
> > > > > On Sun, 03 Feb 2019 20:28:49 +0100
> > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > >
> > > > > > ---
> > > > > > What do you think?
> > > > > >
> > > > >
> > > > > What is the difference with sunrise ?
> > > >
> > > > The difference, as noted in the mail, is that it doesn't rely
> > > > on developers having time to review ebuilds. Therefore, it is
> > > > less likely to die because of developers lacking time to review
> > > > stuff.
> > >
> > >
> > > Then I fear you will see the same pitfalls, and it already started:
> > > I recall sunrise haters being very strongly against the idea
> > > because, TBH, our sandboxing mechanism isn't a real sandbox. It may
> > > have improved, but I doubt it's up to the point that we can safely
> > > run untrusted code there.
> >
> > Sandboxing has nothing to do with security, and trying to 'improve'
> > its security is a waste of time. What's the point of preventing
> > ebuilds from doing malicious things at build time if they can install
> > files that do malicious things afterwards?
>
>
> Because one may or may not run a malicious binary. You are more likely
> to install it. And even more likely to source the ebuild.
1. There are trivial ways to make you run something. Imagine an ebuild
installing into /etc/local.d. Or /etc/cron.d.
2. By design, postinst is run with full privileges. It is meant to
allow ebuilds to run stuff, as root.
--
Best regards,
Michał Górny
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 14:02 ` Michał Górny
@ 2019-02-04 14:25 ` Michael Orlitzky
0 siblings, 0 replies; 24+ messages in thread
From: Michael Orlitzky @ 2019-02-04 14:25 UTC (permalink / raw
To: gentoo-project
On 2/4/19 9:02 AM, Michał Górny wrote:
>
> What is that reason? How is 'blindly accepting community contributions'
> different from 'blindly accepting new developers'? In the former case,
> at least we're not pretending things are secure when they're not.
>
The difference is the amount of effort and foresight involved (which, by
the way, increases with the recent WoT proposal).
It took a few months worth of nights and weekends to become a developer.
Yes, I can commit something malicious -- it will work, and then my
credentials will be revoked. Now if I want to do it again, I have to
come up with a fake name and fake online identity, and then spend at
least a couple weeks re-earning my developer status. As lots of
potential developers (including myself at one time) have pointed out,
that all sucks and nobody wants to do it.
But, with an "official" completely unreviewed repository, I can
compromise everyone who uses it immediately and then do the same thing
again tomorrow. I still think there's some value to it, but it can't be
completely unreviewed and also occupy the same keyword space.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-03 19:28 [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed] Michał Górny
` (2 preceding siblings ...)
2019-02-04 10:58 ` Alexis Ballier
@ 2019-02-04 14:28 ` Virgil Dupras
2019-02-04 14:35 ` Rich Freeman
2019-02-04 17:18 ` Thomas Deutschmann
5 siblings, 0 replies; 24+ messages in thread
From: Virgil Dupras @ 2019-02-04 14:28 UTC (permalink / raw
To: gentoo-project; +Cc: Michał Górny
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
On Sun, 03 Feb 2019 20:28:49 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> Believe me, we don't really review the code of every
> submitted package, and if somebody wrote a program with malicious
> functionality and wanted to package it, it will probably be accepted.
To me, this is a very good argument, not in favor of GURU, but in favor
of halting the proxy-maint project. Being able to trust the security of
the Gentoo tree should be given more priority than allowing users to
get their favorite packages in the tree.
The biggest roadblock to a project like this is the trust issue: I can
end up trusting an individual overlay if I think it's managed well, but
I can't possibly trust GURU for the same reasons I can't trust AUR:
it's inherently insecure.
We can always tell users "but you're supposed to review ebuilds
yourself!", but even with a big fat warning, people will use it in
"yolo" mode and even develop yaourt-like tools to make the yolo mode
easier.
Sure, there might be a demand from some user from this kind of
repository, but like Michael, I think that associating the Gentoo
organisation with this kind of insecure mechanism is unwise.
From what I see in the wild, some overlays are already well organized.
Maybe we should list those well-organized overlays somewhere
"official" to encourage them to grow further?
Virgil
[-- Attachment #2: Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-03 19:28 [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed] Michał Górny
` (3 preceding siblings ...)
2019-02-04 14:28 ` Virgil Dupras
@ 2019-02-04 14:35 ` Rich Freeman
2019-02-04 17:18 ` Thomas Deutschmann
5 siblings, 0 replies; 24+ messages in thread
From: Rich Freeman @ 2019-02-04 14:35 UTC (permalink / raw
To: gentoo-project
On Sun, Feb 3, 2019 at 2:28 PM Michał Górny <mgorny@gentoo.org> wrote:
>
> 1. Should the access be open or explicitly granted? If the latter, how
> should we determine whether to grant access for a particular
> contributor?
>
Obviously we're going for a low barrier to entry here. However, I
think there needs to be SOME kind of reputation system in place (not
necessarily at time of account creation) otherwise we're going to be
open to completely trivial attacks.
One thing I don't like about AUR is that fairly non-exotic packages
end up residing there solely, and updating these becomes tedious,
because you basically have to protect yourself against the script
kiddies. I don't think our intent here is to have the main repository
focus mainly on @system though, so this might not be as much of an
issue.
We probably do need to have some way to keep users from just shooting
themselves in the foot. Unless we have a really strong vetting
process for packages in this alternate repository we're not going to
want to have people just blindingly accepting updates from there. All
that said I think the "AUR Helper" approach Arch uses is a pretty
clunky approach.
I feel like there ought to be some kind of reputation-based solution
where users can earn karma based on actual contributions and then for
updates to be eligible for keywording or whatever they have to be
endorsed by users with enough collective karma or something.
Obviously that is way less trivial to build than a random git repo
that lots of people can push to or whatever.
If we had a reputation-based system then anybody could be allowed to
submit ebuilds without any vetting, since they wouldn't actually
become keyworded/effective/published/whatever until they get vouched
for. However, we'd have to avoid a system where account spam can be
used to play karma games quickly and sneak in packages.
Another approach would be a WoT-like system where users pick what
other users THEY trust and the package manager understands this, so
only ebuilds endorsed by that other user are accepted. Maybe like GPG
there can be trust levels/scores so that more than one endorsement is
allowed. Being end-user-driven this would be much less susceptible to
karma games. It probably would require a lot less micromanagement as
well and there are no longer arguments over who should/shouldn't get
karma as every end user gets to decide for themselves. On the flip
side it does let users shoot themselves in the foot, which I guess is
how we tend to roll here...
Really, though, you have to expect that something like this is going
to get abused. I think the key is to make abuse non-trivial so that
we aren't playing whack-a-mole with rootkit installers.
--
Rich
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 14:13 ` Michał Górny
@ 2019-02-04 14:35 ` Alexis Ballier
2019-02-04 14:43 ` Rich Freeman
0 siblings, 1 reply; 24+ messages in thread
From: Alexis Ballier @ 2019-02-04 14:35 UTC (permalink / raw
To: gentoo-project
On Mon, 04 Feb 2019 15:13:36 +0100
Michał Górny <mgorny@gentoo.org> wrote:
> On Mon, 2019-02-04 at 15:04 +0100, Alexis Ballier wrote:
> > On Mon, 04 Feb 2019 14:54:40 +0100
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> > > On Mon, 2019-02-04 at 14:48 +0100, Alexis Ballier wrote:
> > > > On Mon, 04 Feb 2019 14:28:28 +0100
> > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > >
> > > > > On Mon, 2019-02-04 at 11:58 +0100, Alexis Ballier wrote:
> > > > > > On Sun, 03 Feb 2019 20:28:49 +0100
> > > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > >
> > > > > > > ---
> > > > > > > What do you think?
> > > > > > >
> > > > > >
> > > > > > What is the difference with sunrise ?
> > > > >
> > > > > The difference, as noted in the mail, is that it doesn't rely
> > > > > on developers having time to review ebuilds. Therefore, it is
> > > > > less likely to die because of developers lacking time to
> > > > > review stuff.
> > > >
> > > >
> > > > Then I fear you will see the same pitfalls, and it already
> > > > started: I recall sunrise haters being very strongly against
> > > > the idea because, TBH, our sandboxing mechanism isn't a real
> > > > sandbox. It may have improved, but I doubt it's up to the point
> > > > that we can safely run untrusted code there.
> > >
> > > Sandboxing has nothing to do with security, and trying to
> > > 'improve' its security is a waste of time. What's the point of
> > > preventing ebuilds from doing malicious things at build time if
> > > they can install files that do malicious things afterwards?
> >
> >
> > Because one may or may not run a malicious binary. You are more
> > likely to install it. And even more likely to source the ebuild.
>
> 1. There are trivial ways to make you run something. Imagine an
> ebuild installing into /etc/local.d. Or /etc/cron.d.
Think of an automated QA check for those ebuilds, running some sanity
checks and then uninstalling them.
> 2. By design, postinst is run with full privileges. It is meant to
> allow ebuilds to run stuff, as root.
And that is precisely that kind of design that makes it hard or
unrealistic to have unreviewed global repositories.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 14:35 ` Alexis Ballier
@ 2019-02-04 14:43 ` Rich Freeman
2019-02-04 15:09 ` Alexis Ballier
0 siblings, 1 reply; 24+ messages in thread
From: Rich Freeman @ 2019-02-04 14:43 UTC (permalink / raw
To: gentoo-project
On Mon, Feb 4, 2019 at 9:35 AM Alexis Ballier <aballier@gentoo.org> wrote:
>
> On Mon, 04 Feb 2019 15:13:36 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > 2. By design, postinst is run with full privileges. It is meant to
> > allow ebuilds to run stuff, as root.
>
> And that is precisely that kind of design that makes it hard or
> unrealistic to have unreviewed global repositories.
>
Unless you're doing something like per-app sandboxes at runtime fixing
this is just shifting the problem elsewhere.
Ok, so the package can't run stuff at root at time of install. But,
it can drop whatever shell script it wants into /etc/cron.hourly, or
enable some service by default. Or it can stick something in the
default shell profile. Or it can install /sbin/bash which is ahead of
/bin/bash in PATH, or whatever.
If malware is recognized as a legitimate package by your package
manager, you've basically already lost, at least in the typical
linux/unix-like access control model. Now, if you're doing
unconventional things like android does with uids or putting 3 layers
of SELinux on top of everything then you can have more defense in
depth. But, that also requires sandboxing your package manager so
that it can't tamper with ALL of your security.
As mgorny has already pointed out, you can't just sandbox package
phases to fix the problem. I think sandboxing your build system is a
great way to improve build system QA in general, but it doesn't solve
intrusion.
--
Rich
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 14:43 ` Rich Freeman
@ 2019-02-04 15:09 ` Alexis Ballier
2019-02-04 15:20 ` Rich Freeman
2019-02-04 17:06 ` Ian Stakenvicius
0 siblings, 2 replies; 24+ messages in thread
From: Alexis Ballier @ 2019-02-04 15:09 UTC (permalink / raw
To: gentoo-project
On Mon, 4 Feb 2019 09:43:53 -0500
Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Feb 4, 2019 at 9:35 AM Alexis Ballier <aballier@gentoo.org>
> wrote:
> >
> > On Mon, 04 Feb 2019 15:13:36 +0100
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> > > 2. By design, postinst is run with full privileges. It is meant
> > > to allow ebuilds to run stuff, as root.
> >
> > And that is precisely that kind of design that makes it hard or
> > unrealistic to have unreviewed global repositories.
> >
>
> Unless you're doing something like per-app sandboxes at runtime fixing
> this is just shifting the problem elsewhere.
>
> Ok, so the package can't run stuff at root at time of install. But,
> it can drop whatever shell script it wants into /etc/cron.hourly, or
> enable some service by default. Or it can stick something in the
> default shell profile. Or it can install /sbin/bash which is ahead of
> /bin/bash in PATH, or whatever.
>
> If malware is recognized as a legitimate package by your package
> manager, you've basically already lost, at least in the typical
> linux/unix-like access control model. Now, if you're doing
> unconventional things like android does with uids or putting 3 layers
> of SELinux on top of everything then you can have more defense in
> depth. But, that also requires sandboxing your package manager so
> that it can't tamper with ALL of your security.
>
> As mgorny has already pointed out, you can't just sandbox package
> phases to fix the problem. I think sandboxing your build system is a
> great way to improve build system QA in general, but it doesn't solve
> intrusion.
>
Ok, so the claim here is that installing is more or less the same as
running wrt malicious code. Fine.
Now, I want to install an ebuild from that overlay: I review said
ebuild, seems fine, so I add & enable the overlay. Except, someone just
pushed a malicious app-shells/bash running malicious code at global
scope. Last I checked portage will source it and in the best case
output a warning about running commands at global scope. I am now pwned.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 15:09 ` Alexis Ballier
@ 2019-02-04 15:20 ` Rich Freeman
2019-02-04 17:06 ` Ian Stakenvicius
1 sibling, 0 replies; 24+ messages in thread
From: Rich Freeman @ 2019-02-04 15:20 UTC (permalink / raw
To: gentoo-project
On Mon, Feb 4, 2019 at 10:09 AM Alexis Ballier <aballier@gentoo.org> wrote:
>
> Now, I want to install an ebuild from that overlay: I review said
> ebuild, seems fine, so I add & enable the overlay. Except, someone just
> pushed a malicious app-shells/bash running malicious code at global
> scope. Last I checked portage will source it and in the best case
> output a warning about running commands at global scope. I am now pwned.
>
Sure, hence my comment in my earlier email about having to have more
fine-grained controls around what gets pulled in. You really want
users to be pulling individual packages out of something like this and
not the entire repository, and you don't want even the individual
packages unless they're reviewing every one or somebody else they can
trust is doing so.
You can't just trust something like this the way you'd trust your own
overlay or whatever.
--
Rich
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 15:09 ` Alexis Ballier
2019-02-04 15:20 ` Rich Freeman
@ 2019-02-04 17:06 ` Ian Stakenvicius
2019-02-04 18:32 ` Mike
1 sibling, 1 reply; 24+ messages in thread
From: Ian Stakenvicius @ 2019-02-04 17:06 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1.1: Type: text/plain, Size: 3219 bytes --]
On 2019-02-04 10:09 a.m., Alexis Ballier wrote:
> On Mon, 4 Feb 2019 09:43:53 -0500
> Rich Freeman <rich0@gentoo.org> wrote:
>
>> On Mon, Feb 4, 2019 at 9:35 AM Alexis Ballier <aballier@gentoo.org>
>> wrote:
>>>
>>> On Mon, 04 Feb 2019 15:13:36 +0100
>>> Michał Górny <mgorny@gentoo.org> wrote:
>>>
>>>> 2. By design, postinst is run with full privileges. It is meant
>>>> to allow ebuilds to run stuff, as root.
>>>
>>> And that is precisely that kind of design that makes it hard or
>>> unrealistic to have unreviewed global repositories.
>>>
>>
>> Unless you're doing something like per-app sandboxes at runtime fixing
>> this is just shifting the problem elsewhere.
>>
>> Ok, so the package can't run stuff at root at time of install. But,
>> it can drop whatever shell script it wants into /etc/cron.hourly, or
>> enable some service by default. Or it can stick something in the
>> default shell profile. Or it can install /sbin/bash which is ahead of
>> /bin/bash in PATH, or whatever.
>>
>> If malware is recognized as a legitimate package by your package
>> manager, you've basically already lost, at least in the typical
>> linux/unix-like access control model. Now, if you're doing
>> unconventional things like android does with uids or putting 3 layers
>> of SELinux on top of everything then you can have more defense in
>> depth. But, that also requires sandboxing your package manager so
>> that it can't tamper with ALL of your security.
>>
>> As mgorny has already pointed out, you can't just sandbox package
>> phases to fix the problem. I think sandboxing your build system is a
>> great way to improve build system QA in general, but it doesn't solve
>> intrusion.
>>
>
>
> Ok, so the claim here is that installing is more or less the same as
> running wrt malicious code. Fine.
>
> Now, I want to install an ebuild from that overlay: I review said
> ebuild, seems fine, so I add & enable the overlay. Except, someone just
> pushed a malicious app-shells/bash running malicious code at global
> scope. Last I checked portage will source it and in the best case
> output a warning about running commands at global scope. I am now pwned.
>
All of this doesn't even get to the much more common issue we are
going to face, which is simply that these ebuilds and packages are
more often than not going to be outright broken. The sunrise project
had a big barrier to entry for a lot of folks because of the review
process that enforced ebuild structure and quality well above what
repoman can do. So forgetting about someone actively deciding to
rootkit a bunch of folks, what're we going to do about the ebuilds
that are going to break everyone's deptree resolution, or have a ton
of automagic deps that cause havoc on the next -uDN ?
Even if we do a two-layer repo where the 'public' one is only rolled
forward when a gentoo-ci run passes cleanly, that only fixes so much
AND it'll cause the project to stall when nobody bothers to fix the
blockages. I assume we aren't to the point where gentoo-ci runs on
every individual commit and then kicks out the one(s) that fail while
rebasing to test and accept others...
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-03 19:28 [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed] Michał Górny
` (4 preceding siblings ...)
2019-02-04 14:35 ` Rich Freeman
@ 2019-02-04 17:18 ` Thomas Deutschmann
5 siblings, 0 replies; 24+ messages in thread
From: Thomas Deutschmann @ 2019-02-04 17:18 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1.1: Type: text/plain, Size: 2236 bytes --]
On 2019-02-03 20:28, Michał Górny wrote:
> What do you think?
It is a bad idea, I don't like it:
Like others already said, this _user_ repository will get linked with
_Gentoo_ no matter what you are going to do:
1) Someone isn't able to write a proper ebuild which will satisfy
Gentoo's QA requirements? => It should be in no way connected with "Gentoo".
2) Do you want to see packages moving from main repository to such a
repository? Because people will stop spending time in doing it right if
all they care about is the 'install image' ... exactly this will happen...
3) What about the dependency tree? No cleanup possible because some low
quality ebuild nobody cares about is still depending on an old version
but anything else in the main tree migrated away? Or don't you care
about dependency tree so we are just waiting for the first one copying
ebuilds from main repository to the new user repository to keep the old
version still alive? :>
This will be a nightmare: If this will be successful user will tell
other user "Just enabled GURU repository to get X" -- boom. In the same
moment they have no security support anymore, cannot expect some level
of quality we try to achieve every day...
Please explain: Someone started another motion, "Appeals of Moderation
Decisions" which aims to get rid of the "Off the Wall" sub forum in
forums.gentoo.org. Main argument: The sub forum is damaging Gentoo's
reputation because the content will still get associated with Gentoo
(=people are unable to understand that this is an off topic forum, a
place to bundle trash because in a community you cannot avoid trash at
all). It's funny because OTW exists for more than 10 years now...
You aren't trying to tell us that this is true for the forum but a user
repository wouldn't be a problem because users will understand that this
repository will contain bad stuff or stuff nobody cares about enough to
pass the review process to get into the main repository... it doesn't
matter that this repository will carry Gentoo's name and even has _GLEP_...
No. Please just NO.
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 17:06 ` Ian Stakenvicius
@ 2019-02-04 18:32 ` Mike
2019-02-04 18:44 ` Rich Freeman
0 siblings, 1 reply; 24+ messages in thread
From: Mike @ 2019-02-04 18:32 UTC (permalink / raw
To: gentoo-project
On 2/4/19 12:06 PM, Ian Stakenvicius wrote:
> On 2019-02-04 10:09 a.m., Alexis Ballier wrote:
>> On Mon, 4 Feb 2019 09:43:53 -0500
>> Rich Freeman <rich0@gentoo.org> wrote:
>>
>>> On Mon, Feb 4, 2019 at 9:35 AM Alexis Ballier <aballier@gentoo.org>
>>> wrote:
>>>>
>>>> On Mon, 04 Feb 2019 15:13:36 +0100
Picking random message to reply to.
I guess we should figure out the level of support users can expect to
receive from using this GURU repo. If someone forks a package I
maintain and then a user has issues I'm not sure how much 'official'
support they can expect. Certainly for complicated ebuilds, with
'multiple right' ways of doing things, this could result in an
'official' maintainer being at odds with the 'unoffical' one. Maybe we
have that now?
I came to devship partly through Sunrise, also. The review process was
so intense that I knew not to even submit something with an extra space.
It was a great way to learn. At least for me. The review process was
never as 'agressive' as it seems to be, now. It was supportive and
helpful and the reviewing developers really wanted you to get better.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
2019-02-04 18:32 ` Mike
@ 2019-02-04 18:44 ` Rich Freeman
0 siblings, 0 replies; 24+ messages in thread
From: Rich Freeman @ 2019-02-04 18:44 UTC (permalink / raw
To: gentoo-project
On Mon, Feb 4, 2019 at 1:32 PM Mike <mpagano@gentoo.org> wrote:
>
> I guess we should figure out the level of support users can expect to
> receive from using this GURU repo. If someone forks a package I
> maintain and then a user has issues I'm not sure how much 'official'
> support they can expect. Certainly for complicated ebuilds, with
> 'multiple right' ways of doing things, this could result in an
> 'official' maintainer being at odds with the 'unoffical' one. Maybe we
> have that now?
The original proposal raised that question. IMO we shouldn't allow
namespace conflicts with the main repo. If the main repo has
courier-imap then no package can use that name in GURU. Now, if
somebody wants to maintain some fork of the package under a different
name that is fine.
And again I don't think we want to make it so that when a user
installs one random GURU package that they automatically start pulling
in every other package in that repo like they would a regular overlay.
That will make it much harder for them to stay aware of potential
issues.
That problem can actually exist in the main repo, but in practice it
doesn't come up much. If somebody wanted to stick a renamed chromium
ebuild in the main repo that just defaults to duckduckgo or whatever
that would technically be allowed by policy I believe. However, most
devs are just going to use user patch support to do this sort of
thing, especially considering the effort required to maintain a
parallel package like that. There have been similar arguments over
default USE flags (and associated patches) for stuff like openssh and
bitcoin as well. At least within the main repo we have a pretty
well-defined escalation path for QA/Council/etc.
--
Rich
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2019-02-04 18:44 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-03 19:28 [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed] Michał Górny
2019-02-03 21:29 ` Kristian Fiskerstrand
2019-02-04 5:45 ` Michał Górny
2019-02-03 22:37 ` Michael Orlitzky
2019-02-03 23:08 ` Kristian Fiskerstrand
2019-02-04 10:58 ` Alexis Ballier
2019-02-04 13:28 ` Michał Górny
2019-02-04 13:43 ` Brian Evans
2019-02-04 14:02 ` Michał Górny
2019-02-04 14:25 ` Michael Orlitzky
2019-02-04 13:48 ` Alexis Ballier
2019-02-04 13:54 ` Michał Górny
2019-02-04 14:04 ` Alexis Ballier
2019-02-04 14:13 ` Michał Górny
2019-02-04 14:35 ` Alexis Ballier
2019-02-04 14:43 ` Rich Freeman
2019-02-04 15:09 ` Alexis Ballier
2019-02-04 15:20 ` Rich Freeman
2019-02-04 17:06 ` Ian Stakenvicius
2019-02-04 18:32 ` Mike
2019-02-04 18:44 ` Rich Freeman
2019-02-04 14:28 ` Virgil Dupras
2019-02-04 14:35 ` Rich Freeman
2019-02-04 17:18 ` Thomas Deutschmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox