2008/5/20 Luciano Bello :
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBIM1sdoB+26npOQg4RAihAAJ9fV47D23pCA0YumpCskC bMQR5+ywCeP1WU
XBmZBcnXjgF4q+KXTyv0V3c=
=GiQN
-----END PGP SIGNATURE-----

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-----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)

iD8DBQFIM4mtS9HxQb37XmcRArSXAJ92VD0i7lBncKAt65cOo2 J2s7aq8wCfUsfz
NHsVsPSaxuuaWonjTRuLJ0o=
=ee7/
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

In article <483389AD.5020708@cox.net> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

2008/5/20 Luciano Bello :
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIM9m19LSwzHl+v6sRAqJiAJ9ks+PfecZwttxRUstPZ/ALhPl7OgCeMr8Q
rn9o6d3Z5C3Sv/yeDDC2IuE=
=klwS
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/20/08 23:11, Bernd Eckenfels wrote:
> In article <483389AD.5020708@cox.net> 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+UGDDIKarUy7Yuznus gS1ZxIeACfadoc
3uC4lFzrlrkckOFSJtJWJbQ=
=Z30s
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBINIbyQWTRs4lLtHkRAgzUAJ93pIoWOHbxTLefWbwVDG FXXG5uawCfXddX
Tcn+ERK1vMN4cSaHYa4HO8o=
=iNFW
-----END PGP SIGNATURE-----

In article <200805211732.50086.luciano@debian.org> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 <483389AD.5020708@cox.net> 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 GPG key 0x04880A44


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-----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 <483389AD.5020708@cox.net> 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)

iD8DBQFINNxsS9HxQb37XmcRAlOQAKDO4woqICg8GGO8DMknhx VjJEjW2wCgjYtM
ON91J1pRnNvqsTg2eS4Mst4=
=gey7
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, 2008-05-21 at 06:11:46 +0200, Bernd Eckenfels wrote:
> In article <483389AD.5020708@cox.net> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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?
zack@{upsilon.cc,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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFINurnZN5jenMUa9QRAp7QAJwIcZrCsPX+86cfNNfPBk gyars66gCgjghD
ZTOmsTePCCzbStXbvhZ0PEQ=
=oOEj
-----END PGP SIGNATURE-----

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBINzPuQWTRs4lLtHkRAjTwAKCOWa9tWuosu3ASGKacxt uMMSPzQACgsNoE
o2p6hQ0yUYJCNSuCTK4Yjik=
=5tuP
-----END PGP SIGNATURE-----

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org