Quoting Pekka Savola <pekkas@xxxxxxxxxx>: > OK, let me try to see if I could improve this a bit. > > Use of Bugzilla: > - having to register a fedora.us bugzilla account, it would be better > to use RH's bugzilla if possible/reasonable. > - bugzilla being too user-unfriedly; for example, the GUI at > http://bugzilla.fedora.us/query.cgi has _way_ too many options and > scares people away. You'll definitely want something simpler, like > the interface Red Hat is using. This has been brought up many times, and most users tend to agree, but the powers that be in FL seem to be resistent to change to the bugzilla setup. Due to the overwhelming support for changes to Bugzilla, I really think this needs to be looked into. Maybe an ad-hoc committee to look into it? > Use of PGP signatures: > - Is it necessary to use PGP signatures when reporting at bugzilla? YES! > Bugzilla already provides user authentication, so this only gives > relatively little additional protection. It's much simpler if you > would not need to hassle with PGP at all if you just want to report > whether a package works or not. It's (more) OK to require the use of > PGP for those who submit the actual packages, etc., though. See the security page. Digital signatures are critical to the project. No other way can one establish trust, and the project depends on a trust model to succeed. > Documenting the process very clearly and providing tools to help in > the process: It's a wiki. If you don't like it, change it. If you don't know how to wiki, but want to change it, ask. If you don't know how to wiki, don't want to learn how to, then simply post a patch or update to the mailing list. It is a community project; be part of the community! > - For example: updates-testing says: > > 1. Download the binary RPM package from the updates-testing channel. > 2. Verify the integrity of the downloaded package (see > http://www.fedoralegacy.org/about/security.php). > 3. Install the package, and note any installation problems. > 4. Use the package (as appropriate for the package), and note any > problems found. > > These must be more explicit. What exactly must be verified at "2"? Well, you refer to the link given, which tells you how and what to verify. > How do you report being successful after "4"? You see the next section of the page, IIRC. > The same applies to the rest. I don't see your point. I think you simply failed to follow the links, or read the rest of the page. But that doesn't matter. It is a wiki page. You are free to modify it to make it better. You are free to suggest additions and changes to it. Please participate! > We'll need a (hopefully short and > concise) list which we can point people to, and say "follow these 3 > steps and you're done." There is no such thing. First, above is a 4 step list. You don't like it. So it won't work. Second, each package is different. How you verify a package depends on the package. Different packages need different verification processes. Third, each tester's machine is different. One may install with YUM, one with APT, one with RPM of the binary RPM, one by rebuilding the source SRPM, etc. Some will be missing dependencies. Others will have conflicting packages, or newer versions installed, etc. Some will use lilo, others grub, etc. We can't provide a simple three step process that addresses all the possible situations and variations. > If it's a lot of steps (more than, say, 5), > we'll want to create scripts to help in the process -- e.g., one which > compares the original SRPM and the updated SRPM and shows the results > (recursing through tarballs etc.); one that does the same for > binaries; etc. -- I think these have already circulated on a list half > a year ago or so. Yes. I wish the people with these scripts would put them up in the wiki with instructions on how to use them, etc. So far, no one has taken up my challange to do that, AFAIK. > There should also be more documentation at least on following: > 1) documenting new vulnerabilities (I think Jesse has mostly been > doing this) -- in bugzilla? What isn't covered about this? If you tell me what is missing, I'll add it. If the problem is you don't know where to look, let me know and we'll try to make some cross-links to make things easier to find, or menu changes to make it easier. But you need to tell us what the problem is. > 2) how you proceed if there is new vulnerability in the same package > which is already in the process but not released to updates yet. This is a policy decision we're struggling with, and hence a policy needs to be established. This isn't a documentation issue at this time, as there is no set policy yet. > 3) how do you go about from proposing an updated package (in response > to 1), and how that gets into the build system. This is addressed, as far as I'm concerned, in the docs. If you disagree, we need to talk out why. I think the biggest things right now are bugzilla complaints/changes, and the policy on what to do with updates that have additional changes before they are released. These are real problems, and policy problems. As for docs, I've asked many, many times for people to participate. Only about 3 people have ever taken up the call. We need more paritipation. We need more discussion, more ideas. Please help! Yes, I'm being rather obtuse about the documentation changes recommended above, but it is mostly due to the lack of content in the suggestions. Please address each point separately, and we'll hash them out and get them resolved as best as possible. I'm not against changes or better docs. I just have only so much time to devote to it, and so much talent to go into it, and only one perspective when looking at the docs. I need help to improve them, and the only way, and best way, to get that help is via the participation of as many people as possible in discussion about the current docs or lack thereof. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- Eric Rostetter -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
