Re: Introducing security hardening features for Lenny

[Pierre Habouzit]

On Wed, Mar 05, 2008 at 05:48:57PM +, Kees Cook wrote:
> On Wed, Mar 05, 2008 at 10:16:52AM +0100, Pierre Habouzit wrote:
> > On Wed, Mar 05, 2008 at 06:16:33AM +, Kees Cook wrote:
> > > I finally got some time to run some benchmarks.  I checked the results[1]
> > > into the "hardening" svn tree, in case other people want to contribute
> > > more stuff.
> > 
> >   Thank you very much for those. Though what did you built using -fPIE
> > FORTIFY_SOURCES and so on ? only the tested applications ? or their
> > build-deps as well ? Because I don't expect mplayer to be slowed a lot
> > if you don't rebuild its ogg/mp3/mpg/... as well :) Same goes for
> > inkscape.
> 
> Well, libraries are already -fPIC so there's no need to recompile those.
> As for FORTIFY_SOURCE, that's true, I didn't rebuild the libraries with
> it for these tests.  Getting all libs rebuilt may take a lot longer.  :)

  Well then sadly it makes the benchmarks a lot less interesting :/

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpG5sYdndlVB.pgp
Description: PGP signature

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Mike Bird]

On Wed March 5 2008 14:52:04 Raphael Hertzog wrote:
> On Wed, 05 Mar 2008, Mike Bird wrote:
> > Please post the URL for this policy.  I apologize if you've already
> > posted and I missed it, but Google couldn't find it for me.
>
> http://wiki.debian.org/Teams/Dpkg/GitUsage

Hi Raphael,

I had already seen that policy.  The portions that apply to Ian
are in fact recommendations rather than mandates.

Even if misconstrued as mandates, that policy says that Ian can
rebase as many times as he wants (zero?) and then merge.  You're
arguing that Ian has to rebase as many times as you want (one?).

Where's the dpkg team policy that says Ian has to rebase?  Thanks!

Guillam last summer said that 24 hours to review a change might
not be enough, and left us with the impression that 2 days or
maybe a week would suffice.  It was an opinion but not a policy.

I have not found any policy that says Guillam should have six or
more months to block a change.  Particularly where the blocked
change has been working without significant problems in Ubuntu
for months.

Where is the policy that says Guillam can block a change for six
months?  Thanks!

> Now I would appreciate if you could stop spreading lies and
> aggressive remarks in this thread.

As of this writing it seems that it is in fact you that has
mis-stated dpkg policy.  Specifically: the policy to which you
have posted a link does not state what you have claimed dpkg
policy to be.  Hopefully you are not a liar and that was only a
mistake and you will now post a link which supports your claim.

If not, please retract your mistaken claims concerning dpkg
team policy and permit Ian to get on with improving Debian.

> Find something useful to contribute to Debian.

Debunking the nonsense which has prevented Ian from improving
Debian is a positive contribution.  For an example of a
negative contribution, consider the insecure programmers who
have blocked Ian's excellent work for approximately six months.

--Mike Bird


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Raphael Hertzog]

On Wed, 05 Mar 2008, Mike Bird wrote:
> Please post the URL for this policy.  I apologize if you've already
> posted and I missed it, but Google couldn't find it for me.

http://wiki.debian.org/Teams/Dpkg/GitUsage

Now I would appreciate if you could stop spreading lies and aggressive
remarks in this thread. Find something useful to contribute to Debian.

-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Mike Bird]

On Wed March 5 2008 13:30:06 Otavio Salvador wrote:
> Mike Bird <[EMAIL PROTECTED]> writes:
> > On Wed March 5 2008 12:29:08 Raphael Hertzog wrote:
> >> I've been added to dpkg's Uploader a few weeks ago, I'm not dpkg's main
> >> coordinator. I have no veto power, I was mainly trying to give my view
> >> of the situation ...
> >
> > May I suggest then that if no dpkg maintainer objects here
> > within 48 hours that Ian should proceed with his update?
>
> Obviously NO.
>
> It's a team policy and noone outside of team should override it.

Please post the URL for this policy.  I apologize if you've already
posted and I missed it, but Google couldn't find it for me.  The
most recent I could find was from July 2007[0] wherein it states:

  "We have currently no clear policies about commits."

  "There are currently no clear policies about uploads ... ."

When was this changed to block Ian's work?

Thanks,

--Mike Bird

[0] http://lists.debian.org/debian-dpkg/2007/07/msg00018.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the listmaster team

[Henrique de Moraes Holschuh]

On Wed, 05 Mar 2008, Mike Hommey wrote:
> ... and in a "do what i say, not what i do" fashion, the default sa-exim
> setup (at least in etch) leads to receiving bounce notification because
> of spam being rejected. 

What *is* valid in the context of this thread is the following policy:

  IF the return path of the email is "lists.debian.org",
 AND the email would be rejected or bounced *due to content filtering*,
 AND it has a header "Precedence: list" or "Precedence: bulk",
 then discard it instead of rejecting or bouncing.

I do wish people would be far more explicit about what they mean when they
suggest something that could lead to data loss :-(

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing security hardening features for Lenny

[Don Armstrong]

On Wed, 05 Mar 2008, Kees Cook wrote:
> On Wed, Mar 05, 2008 at 01:29:01AM -0800, Don Armstrong wrote:
> > Just for future reference, it'd probably be better to run more than 5
> > tests of each population in the future
>
> Getting larger data sets will be rather time-consuming -- especially
> for nexuiz which I didn't figure out how to automate.

Yeah; the converse is that since you're really interested in major
differences, 5 samples should be able to detect those.[1]
 
> > t = 0.0722, df = 5.561, p-value = 0.945
> > 95 percent confidence interval:
> >  -0.07382831  0.07822831 
> > sample estimates:
> > mean of x mean of y 
> >   10.8566   10.8544 
> 
> Which of these outputs should be paid attention to?

The p value and the convidence interval are the two things that are
really useful. The first tells you that assuming the true difference
between the means is zero, you would expect to see a difference like
this or larger 94.5% of the time. The second tells you that with 95%
confidence the true difference between the means is between -0.07 and
0.07.
 

Don Armstrong

1: There are sample size calculators where given power (or 1-beta),
alpha, and the difference you wish to detect will give you the number
of samples required.
-- 
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.
 -- Edmund Burke "Thoughts on the Cause of Present Discoontents"

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Loïc Minier]

On Wed, Mar 05, 2008, Mike Bird wrote:
> May I suggest then that if no dpkg maintainer objects here
> within 48 hours that Ian should proceed with his update?

 May you stop in the next hour giving executive advice when you're not
 representing anybody whatsoever?

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP: rain8net -- Rain8Net sprinkler controller application

[rain8net]

Package: wnpp
Severity: wishlist
Owner: Torin Ford <[EMAIL PROTECTED]>


* Package name: rain8net
  Version : 0.0.1
  Upstream Author : Torin Ford <[EMAIL PROTECTED]>
* URL : http://rain8net.sourceforge.net/
* License : GPLv3
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : Rain8Net sprinkler controller application

The Rain8net is a modular 8-zone sprinkler controller device that is  
controlled via an RS-232 serial port. It drives standard 24VAC  
irrigation valves directly. This is a POSIX-compliant CLI program that  
controls Rain8net devices through serial ports.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bits from the listmaster team

[Mike Hommey]

On Tue, Mar 04, 2008 at 03:49:30PM +, Thomas Viehmann wrote:
> Better bounce handling
> ~~
> We checked our bounce handling because we have more than 500 bounces
> for some lists, and in the process found that we didn't have working
> bounce handling for other lists (other-*, deity, *-digest,
> debian-private). There were also problems in handling and recognizing
> mailadresses containing = or ! characters.
> 
> Bounces of debian-private subscription are still manualy handed by the
> listmasters, but we now address these issues and forward such addresses to
> [EMAIL PROTECTED]
> 
> To address the other mailing lists we rewrote some parts of our
> bounce handler.
> 
> While analysing the bounces streaming in, we found that a lot of bounces
> are caused by content filters which reject listmail back to us (which
> violates the RfC). Even worse: the majority of those are false
> positives.
> 
> To let those people know we'll implement a notification system, which
> will notify users about bounces, and remind forcibly removed users about
> their unsubscription.
> 
> This is a service for those people with a temporarily unavailable or
> broken mailbox, so they see that they (or their provider) has a broken
> mail setup or resubscribe back to all lists after their mailaddress is
> functional again.  These notification will be sent out at a maximum of
> once a week, up to a month after the last unsubscription happened.
> 
> Both notification systems are in testing now and will be activated
> shortly after this mail.

... and in a "do what i say, not what i do" fashion, the default sa-exim
setup (at least in etch) leads to receiving bounce notification because
of spam being rejected. 

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Otavio Salvador]

Mike Bird <[EMAIL PROTECTED]> writes:

> On Wed March 5 2008 12:29:08 Raphael Hertzog wrote:
>> I've been added to dpkg's Uploader a few weeks ago, I'm not dpkg's main
>> coordinator. I have no veto power, I was mainly trying to give my view
>> of the situation ...
>
> May I suggest then that if no dpkg maintainer objects here
> within 48 hours that Ian should proceed with his update?

Obviously NO.

It's a team policy and noone outside of team should override it.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Mike Bird]

On Wed March 5 2008 12:29:08 Raphael Hertzog wrote:
> I've been added to dpkg's Uploader a few weeks ago, I'm not dpkg's main
> coordinator. I have no veto power, I was mainly trying to give my view
> of the situation ...

May I suggest then that if no dpkg maintainer objects here
within 48 hours that Ian should proceed with his update?

--Mike Bird


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Raphael Hertzog]

On Wed, 05 Mar 2008, Ian Jackson wrote:
> > What's the difference, really? Isn't it a case of people on all sides
> > trying to control each other instead of cooperating?
> 
> What would you like me to do ?

Either do the supplementary work or wait patiently with some _friendly_
nagging from time to time.

> I'm not trying to control Raphael at all.  I just want his permission
> to go ahead and deploy this important work.

I've been added to dpkg's Uploader a few weeks ago, I'm not dpkg's main
coordinator. I have no veto power, I was mainly trying to give my view
of the situation (the alternative would have been to skip the thread
and nobody from the dpkg team would have responded here because right from
the beginning it was to be expected that the discussion was not going
to be pleasant/productive).

I gave you my advice on the best way to help Guillem review and merge your
work, that's all.

Guillem was ill recently, hopefully he'll catch up soon and will be able
to work on the merge of the triggers branch.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Ian Jackson]

Clint Adams writes ("Re: git bikeshedding (Re: triggers in dpkg, and dpkg 
maintenance)"):
> On Wed, Mar 05, 2008 at 12:55:00AM -0300, Henrique de Moraes Holschuh wrote:
> > Isn't this going way out of proportion?  That's the first I hear from any
> > *refuses* to merge, as opposed to "the merge not going to be done the way I
> > would like it to happen", and "it is taking too long for it to get merged".
> 
> What's the difference, really? Isn't it a case of people on all sides
> trying to control each other instead of cooperating?

What would you like me to do ?

What Raphael is suggesting would result in extra real work for me: Not
only do I have to rework my branch so that my revision logs are pretty
the way he likes.  I would also have to do additional substantial
merge conflict resolution on my flex branch.  This is the most
error-prone part of coding.  It would be completely unnecessary if he
just says `yes'.

I'm not trying to control Raphael at all.  I just want his permission
to go ahead and deploy this important work.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Ian Jackson]

Henrique de Moraes Holschuh writes ("Re: git bikeshedding (Re: triggers in 
dpkg, and dpkg maintenance)"):
> On Tue, 04 Mar 2008, Mike Bird wrote:
> > Raphael seems to have the power to block your packages but he has
> > no rational excuse.  Can the tech committee overrule Raphael or
> > does Debian need to fork a dpkg under more sensible maintainers?
> 
> Isn't this going way out of proportion?  That's the first I hear from any
> *refuses* to merge, as opposed to "the merge not going to be done the way I
> would like it to happen", and "it is taking too long for it to get merged".

These changes have been ready for 6 months and the only thing
preventing me from pushing and uploading them immediately is
Raphael's objection.

I don't even need him to do any work, just say `yes'.

I think that is exactly blocking.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing security hardening features for Lenny

[Matthew Rosewarne]

While these benchmarks should show any differences in raw processing 
performance, there's also the question of what differences the hardening 
measures make to application start-up times.  PIE in particular should cause 
some slowdown when the executables are first run, but it would take some 
other sort of benchmark to determine the impact.  PIE also makes prelinking 
ineffective, so it would probably be worth testing the difference between 
prelinked and PIE executables.

On Wednesday 05 March 2008, Kees Cook wrote:
> I also ran inkscape and nexuiz tests on x86_64, and there was no
> measurable difference.  I'm unclear if this was due to the extra
> registers, or just that that CPU was much faster and the difference
> vanished into the noise.

The x86_64 arch has special hardware to better support PIE, so the lack of any 
noticeable difference in performance is likely due to that.


signature.asc
Description: This is a digitally signed message part.

Re: Who to contact about pointless Ubuntu differences?

[Russ Allbery]

Scott Kitterman <[EMAIL PROTECTED]> writes:

> Definitely.  I'll upload a new revision removing this gratuitous
> difference and leave a note to make clear it's appropriate to sync the
> package.

Thank you very much to both you and Steve.  If this happens again, I'll
mail the Ubuntu maintainer address.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing security hardening features for Lenny

[Steinar H. Gunderson]

On Wed, Mar 05, 2008 at 09:55:37AM -0800, Kees Cook wrote:
>>> t.test(x=c(10.87,10.873,10.854,10.809,10.877),y=c(10.807,10.824,10.963,10.84,10.838))
> What tool is this you're using?

GNU R. Takes a while to get into, but hard to beat for statistics.

>> data:  c(10.87, 10.873, 10.854, 10.809, 10.877) and c(10.807, 10.824, 
>> 10.963, 10.84, 10.838) 
>> t = 0.0722, df = 5.561, p-value = 0.945
>> alternative hypothesis: true difference in means is not equal to 0 
>> 95 percent confidence interval:
>>  -0.07382831  0.07822831 
>> sample estimates:
>> mean of x mean of y 
>>   10.8566   10.8544 
> Which of these outputs should be paid attention to?

The p-value is a good idea. If it's about 0.05, people tend to say the result
is statistically significant. In your case it's 0.945, which means that the
result is for all practical purposes worthless.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing security hardening features for Lenny

[Kees Cook]

On Wed, Mar 05, 2008 at 01:29:01AM -0800, Don Armstrong wrote:
> Just for future reference, it'd probably be better to run more than 5
> tests of each population in the future, as 5 tests means you'll only
> detect very large differences in performance at any reasonable level
> of signifigance.

I suspected.  :)  I'm not much of a statistician, so I saved the
raw data, hoping other folks would hop in to help out on this one.
(Which you have!)

Getting larger data sets will be rather time-consuming -- especially for
nexuiz which I didn't figure out how to automate.

> > t.test(x=c(10.87,10.873,10.854,10.809,10.877),y=c(10.807,10.824,10.963,10.84,10.838))

What tool is this you're using?

>   Welch Two Sample t-test
> 
> data:  c(10.87, 10.873, 10.854, 10.809, 10.877) and c(10.807, 10.824, 10.963, 
> 10.84, 10.838) 
> t = 0.0722, df = 5.561, p-value = 0.945
> alternative hypothesis: true difference in means is not equal to 0 
> 95 percent confidence interval:
>  -0.07382831  0.07822831 
> sample estimates:
> mean of x mean of y 
>   10.8566   10.8544 

Which of these outputs should be paid attention to?

> But useful data nevertheless.[1]
> 
> 1: I won't even begin to discuss how many times I see benchmarks
> without SEM or sd reported.

Heh, well I know of the ideas, but haven't had any practice actually
calculating them.

Thanks!

-Kees

-- 
Kees Cook@outflux.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing security hardening features for Lenny

[Kees Cook]

On Wed, Mar 05, 2008 at 10:16:52AM +0100, Pierre Habouzit wrote:
> On Wed, Mar 05, 2008 at 06:16:33AM +, Kees Cook wrote:
> > I finally got some time to run some benchmarks.  I checked the results[1]
> > into the "hardening" svn tree, in case other people want to contribute
> > more stuff.
> 
>   Thank you very much for those. Though what did you built using -fPIE
> FORTIFY_SOURCES and so on ? only the tested applications ? or their
> build-deps as well ? Because I don't expect mplayer to be slowed a lot
> if you don't rebuild its ogg/mp3/mpg/... as well :) Same goes for
> inkscape.

Well, libraries are already -fPIC so there's no need to recompile those.
As for FORTIFY_SOURCE, that's true, I didn't rebuild the libraries with
it for these tests.  Getting all libs rebuilt may take a lot longer.  :)

-- 
Kees Cook@outflux.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Who to contact about pointless Ubuntu differences?

[Scott Kitterman]

On Wednesday 05 March 2008 03:44, Steve Langasek wrote:
> Hi Russ,
>
> On Tue, Mar 04, 2008 at 11:26:02PM -0800, Russ Allbery wrote:
> > Does anyone know the right contact point to ask Ubuntu to stop making
> > pointless changes to a Debian package?  See:
> >
> > http://patches.ubuntu.com/x/xfonts-jmk/xfonts-jmk_3.0-16ubuntu1.patch
> >
> > I mailed the person listed in the changelog entry here and pointed out
> > that there's no reason to patch a spec file for an Ubuntu or Debian
> > package and didn't get any reply, and then when I uploaded another new
> > version of the package, this pointless change was blindly merged again.
>
> Ugh...
>
> Well, one of the changes mentioned in the changelog is to "Update
> maintainer field in debian/control."  Based on the outcome of the poll
> conducted on (IIRC) debian-project a while back, any modified package in
> Ubuntu is supposed to have a maintainer field that points at the
> responsible party in Ubuntu.  In this case:
>
>  -Maintainer: Russ Allbery <[EMAIL PROTECTED]>
>  +Maintainer: Ubuntu MOTU Developers <[EMAIL PROTECTED]>
>  +XSBC-Original-Maintainer: Russ Allbery <[EMAIL PROTECTED]>
>
> So I would suggest contacting [EMAIL PROTECTED]  Anyone on the
> MOTU team can do an upload to clean up this gratuitous diff so that the
> next time it comes up for merge it will be more obvious that it should be
> synced across instead.
>
> > It doesn't really matter -- it's not hurting anything -- but it's vaguely
> > annoying to have the patch keep showing up on the PTS page when there's
> > no useful content (and it obscures any actually useful modifications made
> > in Ubuntu).
>
> When there are gratuitous diffs between Ubuntu and Debian, it wastes time
> of both the Debian and Ubuntu developers in tracking the differences and
> makes patches.ubuntu.com less useful for everyone.  Better to spend the
> time now to eliminate the unnecessary diff than to have it show up
> repeatedly down the line.

Definitely.  I'll upload a new revision removing this gratuitous difference 
and leave a note to make clear it's appropriate to sync the package.

Scott K


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Clint Adams]

On Wed, Mar 05, 2008 at 12:55:00AM -0300, Henrique de Moraes Holschuh wrote:
> Isn't this going way out of proportion?  That's the first I hear from any
> *refuses* to merge, as opposed to "the merge not going to be done the way I
> would like it to happen", and "it is taking too long for it to get merged".

What's the difference, really? Isn't it a case of people on all sides
trying to control each other instead of cooperating?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#469470: ITP: elisa-plugins-ugly -- Elisa plugins from the "ugly" set

[Philippe Normand]

Package: wnpp
Severity: wishlist
Owner: Philippe Normand <[EMAIL PROTECTED]>

The Elisa project is now shipped in various upstream source
distributions. The -bad plugins set contains Elisa plugins known to be
working well but with code needing more QA (unittests, code
reviews). Moreover the plugins of that bundle might have features
allowing the Elisa user to access media with content-related legal
issues.


* Package name: elisa-plugins-ugly
  Version : 0.3.4
  Upstream Author : Elisa Team <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : GPL3
  Programming Lang: Python
  Description : Elisa plugins from the "ugly" set

 Elisa is a project to create an open source media center solution for
 GNU/Linux and Unix operating systems. Elisa runs on top of the GStreamer
 multimedia framework. In addition to personal video recorder functionality
 (PVR) and Music Jukebox support, Elisa will also interoperate with devices
 following the DLNA standard like Intel's ViiV systems.
 .
 GStreamer is a streaming media framework, based on graphs of filters
 which operate on media data.  Applications using this library can do
 anything from real-time sound processing to playing videos, and just
 about anything else media-related.  Its plugin-based architecture means
 that new data types or processing capabilities can be added simply by
 installing new plug-ins.
 .
 This package contains the Elisa plugins from the "bad" set, a set
 of bad-quality plug-ins.

-- System Information:
Debian Release: lenny/sid
  APT prefers hardy-backports
  APT policy: (500, 'hardy-backports'), (500, 'gutsy-updates'), (500, 
'gutsy-security'), (500, 'gutsy-proposed'), (500, 'gutsy-backports'), (500, 
'gutsy')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-14-generic (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#469464: ITP: elisa-plugins-bad -- Elisa plugins from the "bad" set

[Philippe Normand]

Package: wnpp
Severity: wishlist
Owner: Philippe Normand <[EMAIL PROTECTED]>

The Elisa project is now shipped in various upstream source
distributions. The -bad plugins set contains Elisa plugins known to
be working well but with code needing more QA (unittests, code reviews).

* Package name: elisa-plugins-bad
  Version : 0.3.4
  Upstream Author : Elisa team <[EMAIL PROTECTED]>
* URL : http://elisa.fluendo.com
* License : GPL3
  Programming Lang: Python
  Description : Elisa plugins from the "bad" set

 Elisa is a project to create an open source media center solution for
 GNU/Linux and Unix operating systems. Elisa runs on top of the GStreamer
 multimedia framework. In addition to personal video recorder functionality
 (PVR) and Music Jukebox support, Elisa will also interoperate with devices
 following the DLNA standard like Intel's ViiV systems.
 .
 GStreamer is a streaming media framework, based on graphs of filters
 which operate on media data.  Applications using this library can do
 anything from real-time sound processing to playing videos, and just
 about anything else media-related.  Its plugin-based architecture means
 that new data types or processing capabilities can be added simply by
 installing new plug-ins.
 .
 This package contains the Elisa plugins from the "bad" set, a set
 of bad-quality plug-ins.

-- System Information:
Debian Release: lenny/sid
  APT prefers hardy-backports
  APT policy: (500, 'hardy-backports'), (500, 'gutsy-updates'), (500, 
'gutsy-security'), (500, 'gutsy-proposed'), (500, 'gutsy-backports'), (500, 
'gutsy')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-14-generic (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#469460: ITP: ocamlduce -- OCaml extended with datatypes to manipulate XML documents

[Pietro Abate]

Package: wnpp
Severity: wishlist
Owner: Pietro Abate <[EMAIL PROTECTED]>


* Package name: ocamlduce
  Version : 3.10.0
  Upstream Author : Alain Frisch <[EMAIL PROTECTED]>
* URL : http://cduce.org/ocaml.html
* License : LGPL, QPL
  Programming Lang: OCaml
  Description : OCaml extended with datatypes to manipulate XML documents

 OCamlDuce is a merger between OCaml and CDuce. It comes as a modified
 version of OCaml which integrates CDuce features: XML expressions,
 regular expression types and patterns, iterators. In particular, it
 extends OCaml with a new kind of values to represent XML documents,
 fragments, tags and Unicode strings.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ANSI_X3.4-1968) (ignored: LC_ALL 
set to C)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#469456: ITP: elisa-plugins-good -- Elisa plugins from the "good" set

[Philippe Normand]

Package: wnpp
Severity: wishlist
Owner: Philippe Normand <[EMAIL PROTECTED]>

The Elisa project is now shipped in various upstream source
distributions. The -good plugins set contains Elisa plugins known to
be well tested, working and being compatible with the Elisa licensing
model.

* Package name: elisa-plugins-good
  Version : 0.3.4
  Upstream Author : Elisa team <[EMAIL PROTECTED]>
* URL : http://elisa.fluendo.com
* License : GPL3
  Programming Lang: Python
  Description : Elisa plugins from the "good" set

 Elisa is a project to create an open source media center solution for
 GNU/Linux and Unix operating systems. Elisa runs on top of the GStreamer
 multimedia framework. In addition to personal video recorder functionality
 (PVR) and Music Jukebox support, Elisa will also interoperate with devices
 following the DLNA standard like Intel's ViiV systems.
 .
 GStreamer is a streaming media framework, based on graphs of filters
 which operate on media data.  Applications using this library can do
 anything from real-time sound processing to playing videos, and just
 about anything else media-related.  Its plugin-based architecture means
 that new data types or processing capabilities can be added simply by
 installing new plug-ins.
 .
 This package contains the Elisa plugins from the "good" set, a set
 of good-quality plug-ins.


-- System Information:
Debian Release: lenny/sid
  APT prefers hardy-backports
  APT policy: (500, 'hardy-backports'), (500, 'gutsy-updates'), (500, 
'gutsy-security'), (500, 'gutsy-proposed'), (500, 'gutsy-backports'), (500, 
'gutsy')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-14-generic (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing security hardening features for Lenny

[Don Armstrong]

On Tue, 04 Mar 2008, Kees Cook wrote:
> mplayer doesn't compile with PIE due to the various ASM routines.  (I've
> noted this failure mode in the wiki[2] now.)  However, with everything
> else enabled (including FORTIFY_SOURCE), there was no measurable
> difference (it was below the percentage difference between runs):
> 
> runtime in seconds
> Mplayer Normal  Hardened
> 110.87   10.807  
> 210.873  10.824  
> 310.854  10.963  
> 410.809  10.84   
> 510.877  10.838  


Just for future reference, it'd probably be better to run more than 5
tests of each population in the future, as 5 tests means you'll only
detect very large differences in performance at any reasonable level
of signifigance.

FE:

> t.test(x=c(10.87,10.873,10.854,10.809,10.877),y=c(10.807,10.824,10.963,10.84,10.838))

Welch Two Sample t-test

data:  c(10.87, 10.873, 10.854, 10.809, 10.877) and c(10.807, 10.824, 10.963, 
10.84, 10.838) 
t = 0.0722, df = 5.561, p-value = 0.945
alternative hypothesis: true difference in means is not equal to 0 
95 percent confidence interval:
 -0.07382831  0.07822831 
sample estimates:
mean of x mean of y 
  10.8566   10.8544 

 
> This one showed a possible difference:
> 
> nexuiz  Normal  Hardened
> 1   66.68   68.113  
> 2   66.802  66.93   
> 3   66.758  67.03   
> 4   66.728  67.051  
> 5   66.859  67.037  

While there may be a possible difference here, it's not significant,
given the sample size:

> t.test(x=c(66.68,66.802,66.758,66.728,66.859),y=c(68.113,66.93,67.03,67.051,67.037))

Welch Two Sample t-test

data:  c(66.68, 66.802, 66.758, 66.728, 66.859) and c(68.113, 66.93, 67.03, 
67.051, 67.037) 
t = -2.0899, df = 4.154, p-value = 0.1023
alternative hypothesis: true difference in means is not equal to 0 
95 percent confidence interval:
 -1.0779888  0.1443888 
sample estimates:
mean of x mean of y 
  66.7654   67.2322 

But useful data nevertheless.[1]


Don Armstrong

1: I won't even begin to discuss how many times I see benchmarks
without SEM or sd reported.
-- 
I'd sign up in a hot second for any cellular company whose motto was:
"We're less horrible than a root canal with a cold chisel."
 -- Cory Doctorow

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Introducing security hardening features for Lenny

[Pierre Habouzit]

On Wed, Mar 05, 2008 at 06:16:33AM +, Kees Cook wrote:
> Hi,
> 
> I finally got some time to run some benchmarks.  I checked the results[1]
> into the "hardening" svn tree, in case other people want to contribute
> more stuff.
> 
> On Wed, Jan 30, 2008 at 08:46:55PM +0100, Moritz Muehlenhoff wrote:
> > Video:
> > mplayer with the -benchmark option in conjunction with -nosound and -vo.
> 
> mplayer doesn't compile with PIE due to the various ASM routines.  (I've
> noted this failure mode in the wiki[2] now.)  However, with everything
> else enabled (including FORTIFY_SOURCE), there was no measurable
> difference (it was below the percentage difference between runs):
> 
> runtime in seconds
> Mplayer Normal  Hardened
> 110.87   10.807  
> 210.873  10.824  
> 310.854  10.963  
> 410.809  10.84   
> 510.877  10.838  
> avg  10.8566 10.8544   diff: -0.02%
> error 0.19%   1.00%   
> 
> > HTML rendering:
> > Mike Hommey once blogged about benchmarking the ACID test:
> > http://web.glandium.org/blog/?cat=17
> 
> I followed that to: http://celtickane.com/webdesign/jsspeed2007.php
> The differences between runs were too high for me to use, so I skipped
> this for now.
> 
> > Nexuiz:
> > | To run the benchmark: start Nexuiz & open the console (`) issuing:
> > | timedemo demos/demo1.dem The results will be stored in:
> > | ~/.nexuiz/data/benchmark.log
> 
> This one showed a possible difference:
> 
> nexuiz  Normal  Hardened
> 1   66.68   68.113  
> 2   66.802  66.93   
> 3   66.758  67.03   
> 4   66.728  67.051  
> 5   66.859  67.037  
> avg 66.7654 67.2322  diff: 0.70%
> error0.14%   1.31%   
> 
> So, for nexuiz, with all hardening enabled in i386, there was a
> less-than-1-percent reduction in speed.  Though the error margin for the
> hardened runs were still larger than the measured slow-down.
> 
> > Not sure about XML benchmarks.
> 
> I did parse/render tests with inkscape on i386.  Some of that is XML, but
> I figured it was heavy CPU, which might be worth something.  Note that
> inkscape already compiles with all hardening options (excepting PIE),
> so the "hardened" time differences are entirely due to PIE.  This one
> turned out similar to nexuiz, but with less error.  Again, less than 1
> percent slow-down was seen.
> 
> inkscapeNormal  Hardened
> 1   48.163  48.503  
> 2   48.227  48.535  
> 3   48.267  48.647  
> 4   48.335  48.431  
> 5   48.199  48.587  
> avg 48.2382 48.5406   diff: 0.63%
> error0.20%   0.22%   
> 
> I also ran inkscape and nexuiz tests on x86_64, and there was no
> measurable difference.  I'm unclear if this was due to the extra
> registers, or just that that CPU was much faster and the difference
> vanished into the noise.

  Thank you very much for those. Though what did you built using -fPIE
FORTIFY_SOURCES and so on ? only the tested applications ? or their
build-deps as well ? Because I don't expect mplayer to be slowed a lot
if you don't rebuild its ogg/mp3/mpg/... as well :) Same goes for
inkscape.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpR2vBvGymLM.pgp
Description: PGP signature

Re: Who to contact about pointless Ubuntu differences?

[Steve Langasek]

Hi Russ,

On Tue, Mar 04, 2008 at 11:26:02PM -0800, Russ Allbery wrote:
> Does anyone know the right contact point to ask Ubuntu to stop making
> pointless changes to a Debian package?  See:

> http://patches.ubuntu.com/x/xfonts-jmk/xfonts-jmk_3.0-16ubuntu1.patch

> I mailed the person listed in the changelog entry here and pointed out
> that there's no reason to patch a spec file for an Ubuntu or Debian
> package and didn't get any reply, and then when I uploaded another new
> version of the package, this pointless change was blindly merged again.

Ugh...

Well, one of the changes mentioned in the changelog is to "Update maintainer
field in debian/control."  Based on the outcome of the poll conducted on
(IIRC) debian-project a while back, any modified package in Ubuntu is
supposed to have a maintainer field that points at the responsible party in
Ubuntu.  In this case:

 -Maintainer: Russ Allbery <[EMAIL PROTECTED]>
 +Maintainer: Ubuntu MOTU Developers <[EMAIL PROTECTED]>
 +XSBC-Original-Maintainer: Russ Allbery <[EMAIL PROTECTED]>

So I would suggest contacting [EMAIL PROTECTED]  Anyone on the
MOTU team can do an upload to clean up this gratuitous diff so that the next
time it comes up for merge it will be more obvious that it should be synced
across instead.

> It doesn't really matter -- it's not hurting anything -- but it's vaguely
> annoying to have the patch keep showing up on the PTS page when there's no
> useful content (and it obscures any actually useful modifications made in
> Ubuntu).

When there are gratuitous diffs between Ubuntu and Debian, it wastes time of
both the Debian and Ubuntu developers in tracking the differences and makes
patches.ubuntu.com less useful for everyone.  Better to spend the time now
to eliminate the unnecessary diff than to have it show up repeatedly down
the line.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]