Here is a straw man

1. A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

2. Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

3. Any auto-starting programs must be disclosed.

In 1 "software added to the base install" means Fedora software added, not third-party, right? I'm still pretty solid on asking people to use the Remix branding if they add non-Fedora bits.

In 1 "software added to the base install" means Fedora software added, not third-party, right? I'm still pretty solid on asking people to use the Remix branding if they add non-Fedora bits.

Agreed 100%

Here is a straw man

A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

I agree with this, with the caveat Matt pointed out already.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

That's kind of onerous. Can you tell me, for example, what the default security settings are for Fedora in general? Outside of "SELinux is enabled", I cannot. It also depends on the installed package set and even Edition, given that I think sshd is disabled by default in Workstation but enabled in Server.

Any auto-starting programs must be disclosed.

Why? This one is easier to track given Fedora does have an explicit list for presets, but I think even that differs per Edition slightly.

In 1 "software added to the base install" means Fedora software added, not third-party, right? I'm still pretty solid on asking people to use the Remix branding if they add non-Fedora bits.

This is my intention. I saw this policy as additive so I didn't restate things already in policy.

I believe we should actually consider making them say what image they based their build on and then only speak about variances from that image.

Here is a straw man
A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

I agree with this, with the caveat Matt pointed out already.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

That's kind of onerous. Can you tell me, for example, what the default security settings are for Fedora in general? Outside of "SELinux is enabled", I cannot. It also depends on the installed package set and even Edition, given that I think sshd is disabled by default in Workstation but enabled in Server.

I believe this should be done in the form of "We started with image X and made these changes" This way we don't have to say what the default is, they should instead state what they changed.

Any auto-starting programs must be disclosed.

Why? This one is easier to track given Fedora does have an explicit list for presets, but I think even that differs per Edition slightly.

Again, I believe we should request documentation on any deviation from an image we produce and distribute.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.
That's kind of onerous. Can you tell me, for example, what the default security settings are for Fedora in general? Outside of "SELinux is enabled", I cannot. It also depends on the installed package set and even Edition, given that I think sshd is disabled by default in Workstation but enabled in Server.

I believe this should be done in the form of "We started with image X and made these changes" This way we don't have to say what the default is, they should instead state what they changed.

That's fine. I didn't want people to be required to do a full security audit if they only know "I included packages X, Y, and Z". That's typically the level of change most do, and they aren't likely to be experts in what security implications X,Y, and Z bring.

Any auto-starting programs must be disclosed.
Why? This one is easier to track given Fedora does have an explicit list for presets, but I think even that differs per Edition slightly.

Again, I believe we should request documentation on any deviation from an image we produce and distribute.

I kind of disagree, mostly because we have Spins. Spins don't start from an existing image. They're a net new image. We don't require them to provide a list of changes from one of the Edition images. It is, for the most part, fairly easy for someone to show up and maintain a Spin. I would be willing to bet that the Spins don't get any sort of review for the above in a consistent manner.

Also, it is very easy to install Fedora from an into a VM image with a custom package set then distribute that as a gold master for various usecases. There's nothing to compare that too either.

I understand what you're asking for, but I think it's impractical given that flexibility Fedora has for installation types.

Spins do get different labeling, though — at least, initially. I'm not so sure that we should have reserved the VARIANT in /etc/os-release for editions, but that was the call so that's the current state. Everything not an edition is just generic "Fedora". But anyway, people who are using a spin should know it.

I think we should have stricter rules for using the edition branding, and more relaxed ones for just the Fedora brand. I wonder how specific we need to be. Can we say "clearly state major configuration changes", or "clearly state major configuration changes (for example, disabling SELinux)"?

Here is a straw man

A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

I am torn quite a bit here. I strongly feel that we should make sure that all the software is open and ideally in Fedora. However if a cloud provider has some custom code they need to inject in order to provide a seamless great user experience do we really want to then make them say you can not call it Fedora? an example I can think of is google. google has a bunch of binaries, which includes some services so that users can be injected while the machine continues to run. some of it works with cloud-init but is much less seamless. would we want to have our brand continue to be absent? I would like thatany software they add is packaged as rpms and available via a repo so that updates can be pushed. I would also like to have the vendors clearly disclose that they add software, what it is and that they are responsible for supporting it. I think a big issue that we face is that we have made perpetrated a feeling or belief that we are difficult to work with because of our super strict adherence to how people need to do things. We need to let people know we are open for working with and on and that the process of doing so is for the benefit of everyone.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

We disable the firewall in our own cloud images and do not disclose that. workstation has a watered down set of firewall rules https://src.fedoraproject.org/cgit/rpms/firewalld.git/tree/FedoraWorkstation.xml disabling selinux I think is important, also making it clear that they provide external firewalling etc

Any auto-starting programs must be disclosed.

We do not disclose all services running in any of teh editions or spins today. I would not block on this.

Spins do get different labeling, though — at least, initially. I'm not so sure that we should have reserved the VARIANT in /etc/os-release for editions, but that was the call so that's the current state. Everything not an edition is just generic "Fedora". But anyway, people who are using a spin should know it.
I think we should have stricter rules for using the edition branding, and more relaxed ones for just the Fedora brand. I wonder how specific we need to be. Can we say "clearly state major configuration changes", or "clearly state major configuration changes (for example, disabling SELinux)"?

outside of the filename of the image/iso of a spin there is no distinct branding of the spin. there is nothing in the installed spin that definitively says this was installed from Xfce, LXDE, etc the cloud edition differences have been removed in Fedora 28, so it is no longer uniquely identified either.

Here is a straw man
A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

I am torn quite a bit here. I strongly feel that we should make sure that all the software is open and ideally in Fedora. However if a cloud provider has some custom code they need to inject in order to provide a seamless great user experience do we really want to then make them say you can not call it Fedora? an example I can think of is google. google has a bunch of binaries, which includes some services so that users can be injected while the machine continues to run. some of it works with cloud-init but is much less seamless. would we want to have our brand continue to be absent? I would like thatany software they add is packaged as rpms and available via a repo so that updates can be pushed. I would also like to have the vendors clearly disclose that they add software, what it is and that they are responsible for supporting it. I think a big issue that we face is that we have made perpetrated a feeling or belief that we are difficult to work with because of our super strict adherence to how people need to do things. We need to let people know we are open for working with and on and that the process of doing so is for the benefit of everyone.

I understand your point, and perhaps we need a label for this. I think plain "Fedora" isn't it, though.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

We disable the firewall in our own cloud images and do not disclose that. workstation has a watered down set of firewall rules https://src.fedoraproject.org/cgit/rpms/firewalld.git/tree/FedoraWorkstation.xml disabling selinux I think is important, also making it clear that they provide external firewalling etc

But ours is the template that they need to show variance from. We should discuss these issues in our docs, but this isn't a reason to not ask someone to disclose their variations.

Any auto-starting programs must be disclosed.

We do not disclose all services running in any of teh editions or spins today. I would not block on this.

see above.

@ausil Have you had a chance to look at this at all?

@mattdm https://docs.google.com/document/d/1tfYKaG6ANeEvMYfitA8uRo8Kk9OnC08gcgWE4xbxSyo/edit?usp=sharing has some thoughts, anyone with the link can comment on it

Is there any futher comments or feedback on my proposal?

I will read and review. Sorry for missing your update!

I just left some comments. I think it's good generally, but there are some ambiguities and conflicts to resolve.

We agreed in the last meeting that we're going to put this to a full consensus vote. We will vote in tomorrow's meeting. If you cannot attend tomorrow's meeting, please leave your vote here.

It would be nice to have all comments and suggestions resolved so we are sure of what we are voting on

In today's meeting we agreed that we would reopen comments through Friday of this week, at which point we would do a full consensus vote.

Okay, we're at the deadline. Several more comments have been raised. @ausil, will you please update your draft to reflect those comments so we can begin voting?

@bex to take the draft to legal

@bex is this in legal's hands?

sort of - I need to go poke this

action mattdm ping @bex, see where he left it, and then try to get followup from RH legal, and if I don't get that, or if they come back with disinterest/opposition, close this by the end of the January.

This got sidelined by larger Fedora requests to legal. I would characterize it as still in the last draft state.

I'm going to take this back to legal with a summary of the current state and the planned changes, and why we want to make them. If we don't hear interest back from them, close by end of January as stated above.

The update here was: I talked to them and they asked me to go through the document with more, and I haven't yet. So this is still waiting on me, but for a different reason than before. :-/

Closing this in favor of new #417