Re: what about an special QA package priority?
On Fri, May 23, 2008 at 06:44:39PM +0200, Steinar H. Gunderson wrote: On Fri, May 23, 2008 at 06:03:51PM +0200, Stefano Zacchiroli wrote: So, basically, I welcome your proposal, but IMO its simplest and most effective implementation would be: ``packages scoring high in popcon have to be maintained by teams using some Vcs-*''. Why do you want to force the use of a VCS onto a team? Uh? I'm probably not getting your question, but I do not want to force the use of a _specific_ VCS, if that is what you meant. Assuming that the proposal rationale was to give more visibility to what is going on to a given package, since it is an important one, using _whatever_ VCS sounds like a requirement to me. Of course you need also to specify that it should be public, better if it has a web interface to monitor changes and yada yada ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: what about an special QA package priority?
On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote: I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to manage a hard meticulous QA process in all packages. In the other hand, there are packages more critical than others, which are more delicate to security. The more I think at this proposal of yours, the more I get convinced that the only reasonable definition of delicate is used by a lot of people (i.e. score high in popcoon). As previously noted in this thread other criteria are subjective, and even apparently innocuous packages can open the flank to really serious security problems. So, basically, I welcome your proposal, but IMO its simplest and most effective implementation would be: ``packages scoring high in popcon have to be maintained by teams using some Vcs-*''. To that feel free to add the bells and whistles you want (like valgrind :-P). Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: what about an special QA package priority?
On Tue, 20 May 2008, Luciano Bello wrote: - It should be checked with debugging tools (like valgrind :P) - It should a public VCS These should be encouraged, and in the cases where packages aren't in a public VCS or QAed properly before upload, the deficiencies should be politely pointed out and maintainers encouraged to rectify. - It should maintained by a team Team maintenance doesn't automatically make a package better.[1] Furthermore, I don't believe there are many (possibly any!) packages in Debian where the package is important and the current maintainer wouldn't accept help. [And if there are, that's a problem which we can deal with on a case-by-case basis.] - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) proposed something like this) There isn't enough manpower to do this. While more review is good, blocking development and bug fixing to wait on review is just not sustainable and scalable. [It's not like it's hard for people to interdiff diff.gz's now and see what has changed in each patch; only a few people not directly involved with the package appear to be doing this.] That said, it'd be wonderfull for multiple people to prove me wrong by reviewing all of the patches in base and above, and keep up with the development of those packages while doing so. But I'm not going to hold my breath for it; and we shouldn't hamstring development for it either. Don Armstrong 1: It basically boils down to a problem of manpower; see various other threads which have gone over this in the past. -- A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
On Fri, May 23, 2008 at 06:03:51PM +0200, Stefano Zacchiroli wrote: So, basically, I welcome your proposal, but IMO its simplest and most effective implementation would be: ``packages scoring high in popcon have to be maintained by teams using some Vcs-*''. Why do you want to force the use of a VCS onto a team? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
El Vie 23 May 2008, Don Armstrong escribió: - It should maintained by a team Team maintenance doesn't automatically make a package better.[1] Furthermore, I don't believe there are many (possibly any!) packages in Debian where the package is important and the current maintainer wouldn't accept help. [And if there are, that's a problem which we can deal with on a case-by-case basis.] Is not about accept help. It about considering the package as unmaintained if there is not a team to maintain it. In same packages, we can not depend on only two pairs of eyes. - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) proposed something like this) There isn't enough manpower to do this. While more review is good, blocking development and bug fixing to wait on review is just not sustainable and scalable. [It's not like it's hard for people to interdiff diff.gz's now and see what has changed in each patch; only a few people not directly involved with the package appear to be doing this.] Of course at first is not easy. But we should go to an scenario where all the local patches was reported to upstream (to apply them in the next release) or be justified by more than one developer. I'm just saying the platitude. We need to improve our process. We must learn something from the Debian/OpenSSL debacle. signature.asc Description: This is a digitally signed message part.
Re: what about an special QA package priority?
On Fri, 23 May 2008, Luciano Bello wrote: Is not about accept help. It about considering the package as unmaintained if there is not a team to maintain it. In same packages, we can not depend on only two pairs of eyes. If there aren't enough people who are interested in maintaining packages which are not currently team-maintained packages to make them team maintained, requiring them to be team maintained isn't going to do anything. Are there any packages which aren't team-maintained which have maintainers in the wings who have already contributed to development of the package where the original maintainer hasn't considered team maintainership? Of course at first is not easy. But we should go to an scenario where all the local patches was reported to upstream (to apply them in the next release) or be justified by more than one developer. I'm just saying the platitude. We need to improve our process. We must learn something from the Debian/OpenSSL debacle. We've learned lessons that we already knew: reviewing patches and working to minimize diffs between upstream is good. However, blocking Debian development on upstream or reviewers isn't the way to magically get more people to review Debian-specific patches. We need the people who are doing the review and have continuously committed to doing the review before we block on the review. Don Armstrong -- He was wrong. Nature abhors dimensional abnormalities, and seals them neatly away so that they don't upset people. Nature, in fact, abhors a lot of things, including vacuums, ships called the Marie Celeste, and the chuck keys for electric drills. -- Terry Pratchet _Pyramids_ p166 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
On Saturday 24 May 2008, Don Armstrong wrote: On Fri, 23 May 2008, Luciano Bello wrote: --cut-- Of course at first is not easy. But we should go to an scenario where all the local patches was reported to upstream (to apply them in the next release) or be justified by more than one developer. I'm just saying the platitude. We need to improve our process. We must learn something from the Debian/OpenSSL debacle. We've learned lessons that we already knew: reviewing patches and working to minimize diffs between upstream is good. However, blocking Debian development on upstream or reviewers isn't the way to magically get more people to review Debian-specific patches. If Debian prefers quality to quantity, blocking Debian development to upstream or reviewers is a good thing. There is no magic way to get more people to review Debian-specific patches, but having these extracted and published in a centralized system would improve accessibility and readability to the rest of the world. We need the people who are doing the review and have continuously committed to doing the review before we block on the review. OK, but Debian should help them first revealing its patch material in a more accessible and readable fashion. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
On Wed, 2008-05-21 at 06:11:46 +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: even though it's just a command line utility. Who knows what weird, unexpected side effects there might be from running such an app within a tight bash loop. none*. And not cleaning up yourself also improves performance for short running apps. * unless we talk persistent resources like files or ipc. There's also the case of PIE applications, and someone else dlopening them, althought I don't think this is that common right now. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
2008/5/20 Luciano Bello [EMAIL PROTECTED]: Hi list, I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to manage a hard meticulous QA process in all packages. In the other hand, there are packages more critical than others, which are more delicate to security. Sometimes, those packages have different priorities in the policy meaning. Maybe we can implement this as an Optional header in the control. Thinking about it again, I wonder if that could be implemented using Enrico's DebTags. I think they would be perfect for this. Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
On Wed, May 21, 2008 at 09:00:45AM +0200, Miriam Ruiz wrote: Thinking about it again, I wonder if that could be implemented using Enrico's DebTags. I think they would be perfect for this. Something like #436161 would be the place to start: it's about time to resume that work. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: what about an special QA package priority?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/20/08 23:11, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: even though it's just a command line utility. Who knows what weird, unexpected side effects there might be from running such an app within a tight bash loop. none*. And not cleaning up yourself also improves performance for short running apps. How so? Gruss Bernd * unless we talk persistent resources like files or ipc. That's the point. And what if there's a kernel (or would that be a glibc?) bug? Since you can't know the future of your software (more than once, I've seen a one-off script or program morph-expand into an important and much larger app) or the OS it will run on in the future, it's always good to clean up after yourself. - -- Ron Johnson, Jr. Jefferson LA USA ESPN makes baseball players better. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFINCb2S9HxQb37XmcRAq4WAKCd+UGDDIKarUy7YuznusgS1ZxIeACfadoc 3uC4lFzrlrkckOFSJtJWJbQ= =Z30s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
none*. And not cleaning up yourself also improves performance for short running apps. How so? The libraries request memory from the kernel in pages (4k on i386, will vary on other architectures), they then run thier own heap management system within those pages. Some memory managers will return pagess to the OS when they become completely empty others will not. When the application quits the kernel cleans it up, every page it owns is reclaimed without having to even look at the memory manager structures inside. in other words freeing the memory you have allocated before quitting takes time and achives nothing usefull. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
El Mar 20 May 2008, Nicolas François escribió: It will be hard to define this list of delicate packages. For example, I'm not sure I would have put openssl in the list a few weeks ago. I would have first think about setuid/setgid programs, servers, with high popcon packages first. I agree, we should sharpen the definition of delicate packages: - setuid/setgid programs. - network servers with high popcon (how much is high?) - packages which implements cryptographic algorithms (like python-crypto) What about compilers and interpreters (like gcc and perl)? Kernel and drivers? luciano signature.asc Description: This is a digitally signed message part.
Re: what about an special QA package priority?
On Wed, May 21, 2008 at 08:43:19AM -0500, Ron Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/20/08 23:11, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: even though it's just a command line utility. Who knows what weird, unexpected side effects there might be from running such an app within a tight bash loop. none*. And not cleaning up yourself also improves performance for short running apps. How so? The cleanup is pointless and takes CPU time. Consider a program that does a lot of malloc()s which it uses until it exits. If it really wants to cleanup, it needs to free() every single one which means updating memory allocation structures for every single block of memory that gets freed. And all that for nothing, as the process's whole memory space gets unmapped on exit no matter its contents (including the state of the malloc implementation's allocation management structures). -- Andreas Bombe [EMAIL PROTECTED]GPG key 0x04880A44 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
In article [EMAIL PROTECTED] you wrote: What about compilers and interpreters (like gcc and perl)? Kernel and drivers? Everything which is part of the TCB (libs, login, resolvercache, init, root cron tools, etc). And of course all network clients and all other programs :) Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/21/08 20:08, Andreas Bombe wrote: On Wed, May 21, 2008 at 08:43:19AM -0500, Ron Johnson wrote: On 05/20/08 23:11, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: even though it's just a command line utility. Who knows what weird, unexpected side effects there might be from running such an app within a tight bash loop. none*. And not cleaning up yourself also improves performance for short running apps. How so? The cleanup is pointless and takes CPU time. Consider a program that does a lot of malloc()s which it uses until it exits. If it really wants to cleanup, it needs to free() every single one which means updating memory allocation structures for every single block of memory that gets freed. And all that for nothing, as the process's whole memory space gets unmapped on exit no matter its contents (including the state of the malloc implementation's allocation management structures). I guess that working in the enterprise attunes me to the real possibility that little apps which do one thing then terminate can easily morph into big apps that run forever. Cleaning up after yourself just leaves fewer surprises for the guy who comes after you and makes unanticipated modifications. - -- Ron Johnson, Jr. Jefferson LA USA ESPN makes baseball players better. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFINNxsS9HxQb37XmcRAlOQAKDO4woqICg8GGO8DMknhxVjJEjW2wCgjYtM ON91J1pRnNvqsTg2eS4Mst4= =gey7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
what about an special QA package priority?
Hi list, I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to manage a hard meticulous QA process in all packages. In the other hand, there are packages more critical than others, which are more delicate to security. Sometimes, those packages have different priorities in the policy meaning. Maybe we can implement this as an Optional header in the control. The point is: if we can create critical QA category for delicate packages in the security sense we can have mandatory QA requirement. For example: - It should be checked with debugging tools (like valgrind :P) - It should maintained by a team - It should a public VCS - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) proposed something like this) You can extend or reduce this list. We can discuss about the implementation. But I mainly want to know your opinion. Please, paste the URL if you discussed this in the pass. luciano signature.asc Description: This is a digitally signed message part.
Re: what about an special QA package priority?
2008/5/20 Luciano Bello [EMAIL PROTECTED]: But I mainly want to know your opinion. I think it would be a good idea to have something like that :) Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
Hi, On Tue, 2008-05-20 at 17:21 -0300, Luciano Bello wrote: Hi list, I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to manage a hard meticulous QA process in all packages. In the other hand, there are packages more critical than others, which are more delicate to security. Sometimes, those packages have different priorities in the policy meaning. Maybe we can implement this as an Optional header in the control. The point is: if we can create critical QA category for delicate packages in the security sense we can have mandatory QA requirement. For example: - It should be checked with debugging tools (like valgrind :P) Isn't valgrind how we got into this mess to begin with? - It should maintained by a team - It should a public VCS - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) proposed something like this) You can extend or reduce this list. We can discuss about the implementation. But I mainly want to know your opinion. Please, paste the URL if you discussed this in the pass. luciano I think for critical packages, valgrind prettyness isn't something to care about (unless the interest is generating suppressions). William signature.asc Description: This is a digitally signed message part
Re: what about an special QA package priority?
Hi, On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote: Hi list, I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to manage a hard meticulous QA process in all packages. In the other hand, there are packages more critical than others, which are more delicate to security. Sometimes, those packages have different priorities in the policy meaning. Maybe we can implement this as an Optional header in the control. The point is: if we can create critical QA category for delicate packages in the security sense we can have mandatory QA requirement. It will be hard to define this list of delicate packages. For example, I'm not sure I would have put openssl in the list a few weeks ago. I would have first think about setuid/setgid programs, servers, with high popcon packages first. For example: - It should be checked with debugging tools (like valgrind :P) It's not always needed. It may show some bad practices, but having a command line utility which allocate some resources (memory, syslog, files, PAM, ...) and does not free them directly (i.e. it relies on system to do the cleanup on exit) is not an issue. If you want to improve quality, you can also recommend using checkers (splint, security checkers), code metrics tools (e.g. pmccabe), unit tests It might be good to recommend these tools (including valgrind), and to provide some web services to provide the reports of these tools (IIRC, there is already some servers with rats reports; for other checkers, formalizing some debian/rules rules could help to to start the checkers). But I don't think it will be possible to have them mandatory. - It should maintained by a team We will only be able to advertise that these packages need comaintainers. Or is there a defined response for the delicate packages with no teams/comaintainers. - It should a public VCS - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) proposed something like this) ACK for both. You can extend or reduce this list. We can discuss about the implementation. But I mainly want to know your opinion. I really appreciate the idea, but it might be hard to implement. -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/20/08 18:42, Nicolas François wrote: Hi, On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote: [snip] For example: - It should be checked with debugging tools (like valgrind :P) It's not always needed. It may show some bad practices, but having a command line utility which allocate some resources (memory, syslog, files, PAM, ...) and does not free them directly (i.e. it relies on system to do the cleanup on exit) is not an issue. Still, though, it's Bad Practice not to clean up after yourself, even though it's just a command line utility. Who knows what weird, unexpected side effects there might be from running such an app within a tight bash loop. - -- Ron Johnson, Jr. Jefferson LA USA ESPN makes baseball players better. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIM4mtS9HxQb37XmcRArSXAJ92VD0i7lBncKAt65cOo2J2s7aq8wCfUsfz NHsVsPSaxuuaWonjTRuLJ0o= =ee7/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
Ron Johnson writes: Still, though, it's Bad Practice not to clean up after yourself, even though it's just a command line utility. Who knows what weird, unexpected side effects there might be from running such an app within a tight bash loop. None. If the process exits it exits. It doesn't matter how quickly it is started again. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: what about an special QA package priority?
In article [EMAIL PROTECTED] you wrote: even though it's just a command line utility. Who knows what weird, unexpected side effects there might be from running such an app within a tight bash loop. none*. And not cleaning up yourself also improves performance for short running apps. Gruss Bernd * unless we talk persistent resources like files or ipc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
