9:43 a.m.
Seth,
is is possible to set up builders that the they will have very limited
network connections? Probably just to copr-be or copr-fe?
I'm asking because currently you can do nearly everything on builder.
For example I made evil.spec, which have
%prep
wget http://www.googl.com -O index.html
cat index.html
Which is executed without problem:
http://copr-be.cloud.fedoraproject.org/results/msuchy/copr/fedora-18-x86_...
Of course instead wget I can e.g start my own ssh server or botnet. And
I will own that machine until our timeout expire.
On Koji we do not have such problem because builders are configured to
not allow any internet connections.
Right now we need internet connection on builders, because they need to
download src.rpm. But this can be fixed that user will not provide url
to src.rpm, but they will upload it to cloud-fe. This will be save,
because we will store and behave to src.rpm just as binary file and only
store it in some directory and not parse it.
Builder can then pick it up from copr-fe. Either by downloading from
some http export or via nfs read only share.
Opinions?
Mirek
9:53 a.m.
New subject: Networksetupofbuilders
On Wed, 26 Jun 2013 16:43:39 +0200
Miroslav Suchy <msuchy(a)redhat.com> wrote:
Seth,
is is possible to set up builders that the they will have very
limited network connections? Probably just to copr-be or copr-fe?
I'm asking because currently you can do nearly everything on builder.
For example I made evil.spec, which have
%prep
wget http://www.googl.com -O index.html
cat index.html
Which is executed without problem:
http://copr-be.cloud.fedoraproject.org/results/msuchy/copr/fedora-18-x86_...
Of course instead wget I can e.g start my own ssh server or botnet.
And I will own that machine until our timeout expire.
On Koji we do not have such problem because builders are configured
to not allow any internet connections.
Right now we need internet connection on builders, because they need
to download src.rpm. But this can be fixed that user will not provide
url to src.rpm, but they will upload it to cloud-fe. This will be
save, because we will store and behave to src.rpm just as binary file
and only store it in some directory and not parse it.
Builder can then pick it up from copr-fe. Either by downloading from
some http export or via nfs read only share.
Opinions?
\
Mirek,
All of the above is on purpose and intentional.
Here's why:
1. remember that the user can add random repos to their mock configs in
addition to the urls for their own srpms. Those repos can be from
anywhere - not just from coprs. This is on purpose - so we can support
a wide variety of systems and packages - w/ buildreqs from all over.
2. uploading a 400-1GB pkg to cloud-fe will murder it. Fetching the file
and putting limits on the fetch are MUCH easier
3. the whole point of evil in the builder is that we don't care - the
builders are destroyed once they are used and they do not contain ANY
sensitive information. Furthermore, they are timed out if they are
hanging out for too long.
Remember coprs is not koji and koji is not coprs. Coprs is not a koji
replacement. Coprs is for the space that Koji does not want to and
should not occupy - The untrusted build.
Koji is about creating trusted builds from trusted sources and trusted
contributors.
Coprs is about building pkgs from untrusted sources and
potentially untrusted contributors. This is why we don't touch the rpm
on any system AS an rpm. We only deal with it as files.
So if we were to implement your suggestions we would eliminate:
1. external repositories of any kind
2. pkgs above a certain size
3. pkgs requiring interesting network access to build.
That's not what we want, it's not what our scope or goal is, either.
Does that help explain?
-sv
2:25 p.m.
New subject: Networksetupofbuilders
On 06/26/2013 04:53 PM, seth vidal wrote:
1. remember that the user can add random repos to their mock configs
in
addition to the urls for their own srpms. Those repos can be from
anywhere - not just from coprs. This is on purpose - so we can support
a wide variety of systems and packages - w/ buildreqs from all over.
Why we have such requirement? None build service (including very open
OBS) allows this.
For example OBS allow to build to very wide scale of repositories: Arch,
Debian, Suse, Fedora, RHEL, Mandriva, Ubuntu and many others. But they
always have to be added by build service administrator first.
2. uploading a 400-1GB pkg to cloud-fe will murder it. Fetching the
file
and putting limits on the fetch are MUCH easier
Why? We will have to have work with big packages anyway. For example
package 0ad-data have more than 1GB. I do not see difference if this
file is downloaded by builder or uploaded to cloud-fe. OK there is
subtle difference, we will not need to store src.rpm. But it will be
max. 1/2 of stored data. If you build for more targets (which most user
will) then it will be e.g 1/8 of data. So I do not see problem here.
BTW: We will need some storage with terabytes of free space for sure. Do
we have some? Or I have to start looking around?
3. the whole point of evil in the builder is that we don't care -
the
builders are destroyed once they are used and they do not contain ANY
sensitive information. Furthermore, they are timed out if they are
hanging out for too long.
But the timeout is few hours. And how many builders we will have? OBS
have 400. We will start will smaller number.
I (as attacker) would care less about sensitive information (there is
only one, hard to get, require a lot of work). I would rather welcome
the possibility to get bunch of machines for few hours for free. And
once they timeout I can get them again in few minutes. Ideal for some
botnet or as source of DOS attack.
Remember coprs is not koji and koji is not coprs. Coprs is not a
koji
replacement. Coprs is for the space that Koji does not want to and
should not occupy - The untrusted build.
Koji is about creating trusted builds from trusted sources and trusted
contributors.
Coprs is about building pkgs from untrusted sources and
potentially untrusted contributors. This is why we don't touch the rpm
on any system AS an rpm. We only deal with it as files.
Therefore our whole environment should be more secure than environment
of Koji. Including builders.
So if we were to implement your suggestions we would eliminate:
1. external repositories of any kind
fine with me.
2. pkgs above a certain size
why? I see no problem with
uploading file with GB size.
3. pkgs requiring interesting network access to build.
Such
packages exist? Can you give me example. This is given as case of
bad packing on every packaging workshop.
Does that help explain?
Little bit. Lets continue with
discussion :)
Mirek
3:03 p.m.
New subject: Networksetupofbuilders
On Wed, 26 Jun 2013 21:25:05 +0200
Miroslav Suchy <msuchy(a)redhat.com> wrote:
On 06/26/2013 04:53 PM, seth vidal wrote:
> 1. remember that the user can add random repos to their mock
> configs in addition to the urls for their own srpms. Those repos
> can be from anywhere - not just from coprs. This is on purpose - so
> we can support a wide variety of systems and packages - w/
> buildreqs from all over.
Why we have such requirement? None build service (including very open
OBS) allows this.
For example OBS allow to build to very wide scale of repositories:
Arch, Debian, Suse, Fedora, RHEL, Mandriva, Ubuntu and many others.
But they always have to be added by build service administrator first.
Which is the point. That really only lets you build from the blessed
locations. It's an extra bit of red tape to cut through. Why would we
want to restrict our users in that way?
> 2. uploading a 400-1GB pkg to cloud-fe will murder it. Fetching the
> file and putting limits on the fetch are MUCH easier
Why? We will have to have work with big packages anyway. For example
package 0ad-data have more than 1GB. I do not see difference if this
file is downloaded by builder or uploaded to cloud-fe. OK there is
subtle difference, we will not need to store src.rpm. But it will be
max. 1/2 of stored data. If you build for more targets (which most
user will) then it will be e.g 1/8 of data. So I do not see problem
here.
Have you uploaded a 1GB file to a website from a home network
connection? It's AWFUL. Not to mention we'd need to store this one the
-fe system and the whole goal was to have a separation between -fe and
-be so they didn't need to communicate in anyway but, ultimately REST
Here's how I would use this:
1. construct my spec file(s) locally or over ssh.
2. build srpms on a system <out_in_the_world>
3. put srpms in a webaccessible location
4. paste the srpm urls into the box
5. wait for builds
6. win
BTW: We will need some storage with terabytes of free space for
sure.
Do we have some? Or I have to start looking around?
Our existing private cloud infrastructure has some space - but not
infinite space. The answer I was given was - if this is useful we'll be
able to manifest space for it by adding space onto the private cloud
and more importantly if it is very popular then running out of space is
a good problem to have.
> 3. the whole point of evil in the builder is that we don't
care -
> the builders are destroyed once they are used and they do not
> contain ANY sensitive information. Furthermore, they are timed out
> if they are hanging out for too long.
But the timeout is few hours. And how many builders we will have? OBS
have 400. We will start will smaller number.
I have no idea what OBS has to do with this.
Could you explain what you're talking about here?
I (as attacker) would care less about sensitive information (there is
only one, hard to get, require a lot of work). I would rather welcome
the possibility to get bunch of machines for few hours for free. And
once they timeout I can get them again in few minutes. Ideal for some
botnet or as source of DOS attack.
Your concern here is someone using these systems as a botnet? I think
there are an array of ways to forestall such a thing from happening w/o
restricting all access out from the system.
Off the top of my head I can think of a couple of trivial ways to
verify that the places we're pulling from are repos and not
random websites - whitelisting them through.
What's the REAL risk of this as a botnet? I understand scary
theoretical risk. At the moment the plan was to open up use of this
only to people who are contributors to fedora. The same level of access
required to get access to fedorapeople.org and a fedora alias. That set
of users is far more narrow.
Also - why are you so adamant about this? Maybe I'm misunderstanding
your tone.
If we want to change what the builders are allowed access to
it's not terribly difficult. We just change the security group the
instance is created in to reflect the set of hosts we want it to be
able to access. It's.... well... trivial.
> Remember coprs is not koji and koji is not coprs. Coprs is not
a
> koji replacement. Coprs is for the space that Koji does not want to
> and should not occupy - The untrusted build.
>
> Koji is about creating trusted builds from trusted sources and
> trusted contributors.
>
> Coprs is about building pkgs from untrusted sources and
> potentially untrusted contributors. This is why we don't touch the
> rpm on any system AS an rpm. We only deal with it as files.
Therefore our whole environment should be more secure than
environment of Koji. Including builders.
They are MORE secure. We are not threatened by the builders. The
builders are disposable. If you're concerned that these systems would
be dangerous to others, that's not an entirely unreasonable concern.
However, I don't think that your 'ALL CLOSED' mechanism is a good
way to address that.
> So if we were to implement your suggestions we would eliminate:
> 1. external repositories of any kind
fine with me.
> 2. pkgs above a certain size
why? I see no problem with uploading file with GB size.
> 3. pkgs requiring interesting network access to build.
Such packages exist? Can you give me example. This is given as case
of bad packing on every packaging workshop.
The whole point of this is to allow steaming pile of crap packages to
be built, if people so choose.
COPRs exists b/c the packaging policies of various bodies are too
strict and are a barrier to entry. The Powers-That-Be wanted a place
where people could build whatever package they wanted to build and not
be hampered by bundling or bad build processes or anything.
As to your question of an example, the most recent one I encountered
was a perl module that wanted to talk out to test before it was built.
In fedora the test was disabled, iirc. I'm sure members of the Fedora
Package Committee could comment on some of the nutbar things they've
seen.
-sv
3:58 a.m.
New subject: Networksetupofbuilders
On 06/26/2013 10:03 PM, seth vidal wrote:
Which is the point. That really only lets you build from the blessed
locations. It's an extra bit of red tape to cut through. Why would we
want to restrict our users in that way?
If you (and others) really want this feature. What about that you
provide URL to that repo. It will be synced to copr and then builder
will use the synced repo?
Have you uploaded a 1GB file to a website from a home network
connection? It's AWFUL. Not to mention we'd need to store this one the
Yes. I uploaded even 100 GB.
-fe system and the whole goal was to have a separation between -fe
and
-be so they didn't need to communicate in anyway but, ultimately REST
Why is there such requirement?
Here's how I would use this:
1. construct my spec file(s) locally or over ssh.
2. build srpms on a system <out_in_the_world>
3. put srpms in a webaccessible location
4. paste the srpm urls into the box
5. wait for builds
6. win
On the other hand I always build srpms on local system (which is usually
behind NAT or restrictive firewall). So *I* prefer upload rather then
scp somewhere and pasting URL. Yes uploading over http have little
overhead, but is is just multiply by some constant, so not interesting
from complexity POV.
Our existing private cloud infrastructure has some space - but not
infinite space. The answer I was given was - if this is useful we'll be
Can we know the order of "some space"? Is it MB, GB, TB or PB?
I have no idea what OBS has to do with this.
Could you explain what you're talking about here?
Because it have same purpose, same goal, same requirements. And it is
running for some time. So it can give us idea where we can be one or two
years from now.
Off the top of my head I can think of a couple of trivial ways to
verify that the places we're pulling from are repos and not
random websites - whitelisting them through.
You mean on the iptables level? I would not call that trivial.
Also - why are you so adamant about this? Maybe I'm
misunderstanding
your tone.
Adamant? Nope. I'm just playing devils advocate.
I'm trying to look on COPR from different angles and I'm thinking loudly.
I would rather be prepared for scenario, which will never happen than
experience issue for which we will not be prepared.
The whole point of this is to allow steaming pile of crap packages
to
be built, if people so choose.
COPRs exists b/c the packaging policies of various bodies are too
strict and are a barrier to entry. The Powers-That-Be wanted a place
where people could build whatever package they wanted to build and not
be hampered by bundling or bad build processes or anything.
Really? That differ from my expectations. I do not want to encourage
people to build crap (by allowing them to).
Maybe it is time to recap what are the primary target audience of Copr.
At least how I feel it, because I never seen that written or discussed:
1) various upstream projects (e.g OpenShift, Katello, etc. - but even
small one man projects), which want to build theirs nightlies in
reproducible manner.
2) projects which consist of lot of packages and it would take long time
for them to go through Package Review process (either because it is
simply too much packages or because they are e.g. bundling libraries and
it takes some time to fix the code to follow Fedora guideliness) and
they want to offer their releases right now.
3) Projects which want to offer release for different platform than
Fedora/EPEL. E.g. Suse, but I would count here even Software
Collections, Secondary Architectures.
4) Repos which should be private for some reasons (embargoed builds
which should be tested)
Do I perceive it correctly? Feel free to correct me or add what I'm missing.
--
Miroslav Suchy
Red Hat Systems Management Engineering
12:17 p.m.
New subject: Networksetupofbuilders
On Thu, Jun 27, 2013 at 10:58:09AM +0200, Miroslav Suchý wrote:
>The whole point of this is to allow steaming pile of crap packages to
>be built, if people so choose.
>
>COPRs exists b/c the packaging policies of various bodies are too
>strict and are a barrier to entry. The Powers-That-Be wanted a place
>where people could build whatever package they wanted to build and not
>be hampered by bundling or bad build processes or anything.
Really? That differ from my expectations. I do not want to encourage
people to build crap (by allowing them to).
Maybe it is time to recap what are the primary target audience of
Copr. At least how I feel it, because I never seen that written or
discussed:
1) various upstream projects (e.g OpenShift, Katello, etc. - but even
small one man projects), which want to build theirs nightlies in
reproducible manner.
+1
2) projects which consist of lot of packages and it would take long
time for them to go through Package Review process (either because it
is simply too much packages or because they are e.g. bundling
libraries and it takes some time to fix the code to follow Fedora
guideliness) and they want to offer their releases right now.
+1 -- note that this is a subset of the noted "streaming pile of crap
packages" :-)
3) Projects which want to offer release for different platform than
Fedora/EPEL. E.g. Suse, but I would count here even Software
Collections, Secondary Architectures.
-1 Software Collections perhaps, but the other uses are out of scope. Secondary
arches, for instance, require copr-be hardware for the arch to be available.
4) Repos which should be private for some reasons (embargoed builds
which should be tested)
+0 -- I think this is out of scope but I suppose the scope could be expanded
to encompas it. I'm a little leery of it though.... Part of what makes the
legal ramifications of copr work is that we're crowdsourcing the monitoring
of what's being hosted in coprs. Having private repos eliminates that
check.
Do I perceive it correctly? Feel free to correct me or add what
I'm missing.
Just my thoughts on what the scope is.
-Toshio
9:58 p.m.
New subject: Networksetupofbuilders
On Thu, 27 Jun 2013 10:17:00 -0700
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
> 3) Projects which want to offer release for different platform than
> Fedora/EPEL. E.g. Suse, but I would count here even Software
> Collections, Secondary Architectures.
-1 Software Collections perhaps, but the other uses are out of
scope. Secondary arches, for instance, require copr-be hardware for
the arch to be available.
Which, in the case of arm, rumor has it - we will have access to (in
one way or another).
> 4) Repos which should be private for some reasons (embargoed builds
> which should be tested)
>
+0 -- I think this is out of scope but I suppose the scope could be
expanded to encompas it. I'm a little leery of it though.... Part of
what makes the legal ramifications of copr work is that we're
crowdsourcing the monitoring of what's being hosted in coprs. Having
private repos eliminates that check.
Private repos has been specifically requested by various powers that be.
The gist of the private repos is to allow someone to build something
and put a password on the repo to restrict access to it. That's really
all. So think of it less as a 'private' repo and more as a 'not public'
repo.
I can definitely see the advantage of being able to build something in
a copr with a password. Email the password out to a mailing list of
people and tell them to go test it. Not for purposes of keeping it
private but to keep it from being stumbled upon, either b/c it is not
ready for public consumption or b/c you are worried it might eat babies.
Otherwise I agree with the scopes you outlined.
-sv
10:53 p.m.
New subject: Networksetupofbuilders
On Thu, 27 Jun 2013 10:58:09 +0200
Miroslav Suchý <msuchy(a)redhat.com> wrote:
On 06/26/2013 10:03 PM, seth vidal wrote:
> Which is the point. That really only lets you build from the blessed
> locations. It's an extra bit of red tape to cut through. Why would
> we want to restrict our users in that way?
If you (and others) really want this feature. What about that you
provide URL to that repo. It will be synced to copr and then builder
will use the synced repo?
As Rex pointed out - the point of this is to lower barriers - not put
more up.
> Have you uploaded a 1GB file to a website from a home network
> connection? It's AWFUL. Not to mention we'd need to store this one
> the
Yes. I uploaded even 100 GB.
I'm glad you have such good network access. I do
not. A lot of the
world does not.
If you want to add in functionality to upload files I won't to
block it - but I do not want that at the cost of removing remote file
downloads. If you lobby to remove remote file downloads on builders
you're going to be creating a lot of problems for yourself.
Please don't make us start having to get approval on individual patches.
> -fe system and the whole goal was to have a separation between -fe
> and -be so they didn't need to communicate in anyway but,
> ultimately REST
Why is there such requirement?
B/c it makes sense - b/c it cleanly separates the FE and BE?
> Here's how I would use this:
>
> 1. construct my spec file(s) locally or over ssh.
> 2. build srpms on a system <out_in_the_world>
> 3. put srpms in a webaccessible location
> 4. paste the srpm urls into the box
> 5. wait for builds
> 6. win
On the other hand I always build srpms on local system (which is
usually behind NAT or restrictive firewall). So *I* prefer upload
rather then scp somewhere and pasting URL. Yes uploading over http
have little overhead, but is is just multiply by some constant, so
not interesting from complexity POV.
And yet it means we have to be able to house and cope with those on the
frontend and write them out. I'd really rather them not ever be there
specificaly for the security and integrity of our own systems.
> Our existing private cloud infrastructure has some space - but not
> infinite space. The answer I was given was - if this is useful
> we'll be
Can we know the order of "some space"? Is it MB, GB, TB or PB?
We have a about 400GB allocated right now and we could probably add
another 600GB before we need to look for more space for cinder volume
servers.
So let's call it about 1tb at the moment.
> Off the top of my head I can think of a couple of trivial ways to
> verify that the places we're pulling from are repos and not
> random websites - whitelisting them through.
You mean on the iptables level? I would not call that trivial.
Actually I mean on the private cloud security groups level.
Iptables on the builder would be meaningless - anyone who can install a
package into the chroot is effectively root. rpm pkgs are installed as
root and any root user can walk out of a chroot - counting on iptables
on the buildsystem is unsafe - we'd need to do it with security groups
in the cloud system.
Adamant? Nope. I'm just playing devils advocate.
Please don't. You'd be much more help just by helping rather than
making me and others defend decisions and plans we made before.
I'm trying to look on COPR from different angles and I'm
thinking
loudly. I would rather be prepared for scenario, which will never
happen than experience issue for which we will not be prepared.
I'd rather we work on the specific items that are left to do, get this
available to all fedora packagers and adapt as we need to.
Perfect is the enemy of the good.
Really? That differ from my expectations. I do not want to encourage
people to build crap (by allowing them to).
Maybe it is time to recap what are the primary target audience of
Copr. At least how I feel it, because I never seen that written or
discussed:
COPR IS FOR ANY PACKAGE NO MATTER THE QUALITY.
I put that in caps to make sure it was not misssed.
It is absolutely mandatory that we are not imposing packaging policies
or rules on anything that goes in coprs.
Exceptions to this rule include:
1. packages which cannot build (by default of course)
2. packages which are not legal to be build ie: don't have a
valid/acceptable license tag.
otherwise ANYTHING goes.
1) various upstream projects (e.g OpenShift, Katello, etc. - but even
small one man projects), which want to build theirs nightlies in
reproducible manner.
Sure.
2) projects which consist of lot of packages and it would take long
time for them to go through Package Review process (either because it
is simply too much packages or because they are e.g. bundling
libraries and it takes some time to fix the code to follow Fedora
guideliness) and they want to offer their releases right now.
Sure.
3) Projects which want to offer release for different platform than
Fedora/EPEL. E.g. Suse, but I would count here even Software
Collections, Secondary Architectures.
Sure - provided we have it.
4) Repos which should be private for some reasons (embargoed builds
which should be tested)
sure.
Do I perceive it correctly? Feel free to correct me or add what I'm
missing.
Okay
5. Crap.
Let a thousand flowers bloom and we'll pick the best ones later. The
crap gets mowed under for compost.
-sv
3:37 a.m.
New subject: Networksetupofbuilders
----- Original Message -----
On Thu, 27 Jun 2013 10:58:09 +0200
Miroslav Suchý <msuchy(a)redhat.com> wrote:
> On 06/26/2013 10:03 PM, seth vidal wrote:
> > Which is the point. That really only lets you build from the blessed
> > locations. It's an extra bit of red tape to cut through. Why would
> > we want to restrict our users in that way?
>
> If you (and others) really want this feature. What about that you
> provide URL to that repo. It will be synced to copr and then builder
> will use the synced repo?
As Rex pointed out - the point of this is to lower barriers - not put
more up.
IMO having the ability to get build deps from outside repos is very important for Copr.
How we want to achieve that is a different question.
Syncing repo may be very expensive. Think of scenario with 100G repo, out of which Copr
builds only use 1M of packages (a cornercase yes, but still...). Generally, I think both
approaches have their downsides, but I'm currently more convinced that letting
builders download the packages is the way to go.
> > Have you uploaded a 1GB file to a website from a home
network
> > connection? It's AWFUL. Not to mention we'd need to store this one
> > the
>
> Yes. I uploaded even 100 GB.
I'm glad you have such good network access. I do not. A lot of the
world does not.
If you want to add in functionality to upload files I won't to
block it - but I do not want that at the cost of removing remote file
downloads. If you lobby to remove remote file downloads on builders
you're going to be creating a lot of problems for yourself.
Please don't make us start having to get approval on individual patches.
So IMHO this is more about separating building process into multiple steps:
making SRPM available -> providing SRPM to backend -> building SRPM
And by "making SRPM available" I mean in any way possible - upload it somewhere
and just point to it or upload it to frontend, which will then place it somewhere where
backend can pick it up. We can do both cases easily.
>
> > -fe system and the whole goal was to have a separation between -fe
> > and -be so they didn't need to communicate in anyway but,
> > ultimately REST
>
> Why is there such requirement?
B/c it makes sense - b/c it cleanly separates the FE and BE?
I think that separating the functionality into two communicating entities will pay off in
the long run. It allows us to swap the parts without changing the way the other parts
work.
> > Here's how I would use this:
> >
> > 1. construct my spec file(s) locally or over ssh.
> > 2. build srpms on a system <out_in_the_world>
> > 3. put srpms in a webaccessible location
> > 4. paste the srpm urls into the box
> > 5. wait for builds
> > 6. win
>
> On the other hand I always build srpms on local system (which is
> usually behind NAT or restrictive firewall). So *I* prefer upload
> rather then scp somewhere and pasting URL. Yes uploading over http
> have little overhead, but is is just multiply by some constant, so
> not interesting from complexity POV.
And yet it means we have to be able to house and cope with those on the
frontend and write them out. I'd really rather them not ever be there
specificaly for the security and integrity of our own systems.
>
>
> > Our existing private cloud infrastructure has some space - but not
> > infinite space. The answer I was given was - if this is useful
> > we'll be
>
> Can we know the order of "some space"? Is it MB, GB, TB or PB?
We have a about 400GB allocated right now and we could probably add
another 600GB before we need to look for more space for cinder volume
servers.
So let's call it about 1tb at the moment.
>
> > Off the top of my head I can think of a couple of trivial ways to
> > verify that the places we're pulling from are repos and not
> > random websites - whitelisting them through.
>
> You mean on the iptables level? I would not call that trivial.
Actually I mean on the private cloud security groups level.
Iptables on the builder would be meaningless - anyone who can install a
package into the chroot is effectively root. rpm pkgs are installed as
root and any root user can walk out of a chroot - counting on iptables
on the buildsystem is unsafe - we'd need to do it with security groups
in the cloud system.
>
> Adamant? Nope. I'm just playing devils advocate.
Please don't. You'd be much more help just by helping rather than
making me and others defend decisions and plans we made before.
> I'm trying to look on COPR from different angles and I'm thinking
> loudly. I would rather be prepared for scenario, which will never
> happen than experience issue for which we will not be prepared.
I'd rather we work on the specific items that are left to do, get this
available to all fedora packagers and adapt as we need to.
Perfect is the enemy of the good.
> Really? That differ from my expectations. I do not want to encourage
> people to build crap (by allowing them to).
> Maybe it is time to recap what are the primary target audience of
> Copr. At least how I feel it, because I never seen that written or
> discussed:
COPR IS FOR ANY PACKAGE NO MATTER THE QUALITY.
I put that in caps to make sure it was not misssed.
It is absolutely mandatory that we are not imposing packaging policies
or rules on anything that goes in coprs.
Exceptions to this rule include:
1. packages which cannot build (by default of course)
2. packages which are not legal to be build ie: don't have a
valid/acceptable license tag.
otherwise ANYTHING goes.
+1. If we try to enforce any sort of packaging guidelines, we will end up where Fedora
currently is with all the guidelines and stuff (which is what we don't want).
Let's keep Copr free, if users want to build crap, then let them.
>
> 1) various upstream projects (e.g OpenShift, Katello, etc. - but even
> small one man projects), which want to build theirs nightlies in
> reproducible manner.
Sure.
> 2) projects which consist of lot of packages and it would take long
> time for them to go through Package Review process (either because it
> is simply too much packages or because they are e.g. bundling
> libraries and it takes some time to fix the code to follow Fedora
> guideliness) and they want to offer their releases right now.
Sure.
> 3) Projects which want to offer release for different platform than
> Fedora/EPEL. E.g. Suse, but I would count here even Software
> Collections, Secondary Architectures.
Sure - provided we have it.
> 4) Repos which should be private for some reasons (embargoed builds
> which should be tested)
sure.
>
> Do I perceive it correctly? Feel free to correct me or add what I'm
> missing.
Okay
5. Crap.
Agreed all 5.
Let a thousand flowers bloom and we'll pick the best ones later. The
crap gets mowed under for compost.
-sv
--
Regards,
Bohuslav "Slavek" Kabrda.
3:46 a.m.
New subject: Networksetupofbuilders
On 07/02/2013 05:53 AM, seth vidal wrote:
> >
> >Adamant? Nope. I'm just playing devils advocate.
Please don't. You'd be much more help just by helping rather than
making me and others defend decisions and plans we made before.
The problem is that those decisions (and their reasoning) was not
written, so I (and others) do not know about it, so I'm asking.
--
Miroslav Suchy
Red Hat, Software Engineer
2:16 p.m.
New subject: Networksetupofbuilders
On Mon, 1 Jul 2013 23:53:30 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
Actually I mean on the private cloud security groups level.
Iptables on the builder would be meaningless - anyone who can install
a package into the chroot is effectively root. rpm pkgs are installed
as root and any root user can walk out of a chroot - counting on
iptables on the buildsystem is unsafe - we'd need to do it with
security groups in the cloud system.
I wanted to add something here - we can easily restrict external access
from these boxes to port 80 or 443 on any system anywhere, and nothing
else.
I don't think that's an unreasonable limitation on users and it does
help prevent someone from leaping off overly much from one of those
systems.
-sv
3944
days inactive
3950
days old
copr-devel@lists.fedorahosted.org
10 comments
4 participants
participants (4)
-
Bohuslav Kabrda -
Miroslav Suchý -
Seth Vidal -
Toshio Kuratomi