Bug#584636: ITP: cmor -- Climate Model Ouput Rewriter

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: cmor
  Version : 2.0
  Upstream Author : Charles Doutriaux 
* URL : http://www2-pcmdi.llnl.gov/cmor
* License : "Unrestricted" (BSD-like ?)
  Programming Lang: C, python, fortran
  Description : Climate Model Ouput Rewriter

The "Climate Model Output Rewriter" (CMOR, pronounced "Seymour") comprises a 
set of C-based functions, with bindings to both Python and FORTRAN 
90, 
that can be used to produce CF-compliant netCDF files that fulfill the 
requirements of many of the climate community's standard model experiments. 
These experiments are collectively referred to as MIP's and include, for 
example, AMIP, CMIP, CFMIP, PMIP, APE, and IPCC scenario runs. The output 
resulting from CMOR is "self-describing" and facilitates analysis of results 
across models.

Much of the metadata written to the output files is defined in MIP-specific 
tables, typically made available from each MIP's web site. CMOR relies on 
these tables to provide much of the metadata that is needed in the MIP context, 
thereby reducing the programming effort required of the individual MIP 
contributors.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100605082105.25291.75283.report...@ailm.sceal.ie

Bug#584637: ITP: cdat -- Climate Data Analysis Tools

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: cdat
  Version : 5.2
  Upstream Author : Dean Williams (william...@llnl.gov)
* URL : http://www2-pcmdi.llnl.gov/cdat
* License : BSD
  Programming Lang: python, c, fortran
  Description : Climate Data Analysis Tools

CDAT makes use of an open-source, object-oriented, easy-to-learn scripting 
language (Python) to link together separate software subsystems and packages 
to form an integrated environment for data analysis. Outside collaborators work 
independently and contribute on an equal basis with PCMDI. 

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100605082600.25412.99791.report...@ailm.sceal.ie

Bug#584650: ITP: openlayers -- JavaScript library for map applications on the web.

[Thomas Bechtold]

Package: wnpp
Severity: wishlist
Owner: Thomas Bechtold 


* Package name: openlayers
  Version : 2.9.1
  Upstream Author : MetaCarta
* URL : http://openlayers.org/
* License : BSD style License
  Programming Lang: Javascript
  Description : JavaScript library for map applications on the web.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100605093916.28687.25935.report...@zitrone

Re: pid file security

[Luke Kenneth Casson Leighton]

On Sat, Jun 5, 2010 at 2:26 AM, Russell Coker  wrote:
> On Sat, 5 Jun 2010, Luke Kenneth Casson Leighton 
> wrote:
>> apologies for butting-in without being able to continue the thread,
>> but i've just seen this:
>> http://advogato.org/person/etbe/diary/779.html
>> which links to this:
>> http://lists.debian.org/debian-devel/2010/05/msg00067.html
>
> http://etbe.coker.com.au/2010/06/04/securely-killing-processes/
>
> You're quick.

 :)  it was pure chance: i saw it in advogato recentlog, which flashes
by in a blur.

> http://sourceforge.net/projects/depinit/
>
> The above URL is one place to download depinit.  It's an init replacement that
> uses configuration files to give the details of services to start.

 yes.  it's worth explicitly mentioning that it's a parallel-capable
replacement for sysv init, and a bit more besides.  it doesn't use
inittab, for example.  in another project that he did, richard i think
even wrote his own /bin/login replacement because he didn't like the
ones that were on offer _either_ :) which he then fired off from
depinit, via a signal that is i believe generated for extraneous
key-presses such as ctrl-alt-delete or alt-left or alt-right; in this
way, pressing alt-right fired up another login console.

>> depinit solved the fork-bombing issue because richard lightman was
>> concerned about attacks on his internet-facing system.  richard added
>> code which actively tracks child signals (depinit is highly unusual
>> and innovative in that it catches ALL signals, and can therefore react
>> _to_ any signal) and analyses the timing etc. and provides a means to
>> trigger arbitrary "scripts" based on the signal type.
>
> How does it do that?  Does it ptrace them?

 i don't honestly know. richard was the complete frigging introverted
genius, here, not me :)

> http://etbe.coker.com.au/2010/05/16/systemd-init/
>
> How does [depinit] prevent processes escaping?

 reaally don't know.  apologies.

>> richard also solved the security PID problem ... by doing away with
>> the need for the PID file.
>
> That doesn't do away with the need for arbitrary programs to kill other
> arbitrary programs and not make a mistake about which program they are
> killing.

 yes.  correct.  i believe that depinit can manage / knows about only
the services which it initiates, and are under its immediate control,
by capturing all (16?) signals of its immediate child processes.

>> FOREGROUND=True or whatever it is) and so on.  in this way, there
>> simply _is_ no need for a PID file, period.  the relevant state
>> information is contained within depinit itself, and you can guarantee
>> that depinit will catch the signal.
>
> systemd does all that.

 excellent.

>> and looked for "unauthorised login" attempts.  more than three of
>> those occurring within a specified time, and iptables would be called
>> to block that user's IP address.  voila: no delays due to syslog
>> polling: instant and real-time attacker blocking, all using simple
>
> Does a program that uses inotify to wait for log file changes on disk
> experience any delay of note?

 ... no - you're right: it wouldn't.  so that would be a solution
but again, it would require an application that had that capability
[to use notify] - times however many services you wanted to react to,
in real-time.  so, an sshd-monitoring application would need to be
written (in c?) to wait for inotify; an apache2-monitoring application
would... etc. etc.

 however if that functionality was built-in to systemd, just as it is
already built-in to depinit, i.e. if the services which were fired off
foreground-style by systemd could have their stdin, stdout and stderr
redirected to applications/scripts, as specified by command-line
options to systemd...

> The systemd option of creating sockets before executing services that listen
> to them seems to offer the potential of more significant boot performance
> benefits than just starting things in parallel.

 that's got my eyebrows raised - how the heck does _that_ work?  i'm
both surprised and intrigued.

 ok, darn it - systemd seems to be a really bad name choice: google
search comes up with "Systeme D", and also systemd on windows??

 ok, let's read this:
 http://etbe.coker.com.au/2010/05/16/systemd-init/

 okaaay, riight.  so.  ah ha.  it makes things quicker... by avoiding
starting the services _entirely_ :)  ok, so systemd is a merging of
the functionality of sysv init and also inetd.

 right.  let me think.  insights.  ok.  inetd.  usually inetd (and
presumably systemd) services have their stdin and stdout redirected to
the TCP/UDP ports, and you pass a specific option to the service to
tell it that you want that to happen.  that leaves stderr available
for error/info logging... so yes, systemd could in fact be enhanced to
do the same job as depinit [wrt the real-time reacting _without_
having to use polling or inotify].

 second: assuming that systemd is _only_ capable of starting up
services [as an inetd replacem

Re: pid file security

[Tollef Fog Heen]

]] Luke Kenneth Casson Leighton 

| > Does a program that uses inotify to wait for log file changes on disk
| > experience any delay of note?
| 
|  ... no - you're right: it wouldn't.  so that would be a solution
| but again, it would require an application that had that capability
| [to use notify] - times however many services you wanted to react to,
| in real-time.  so, an sshd-monitoring application would need to be
| written (in c?) to wait for inotify; an apache2-monitoring application
| would... etc. etc.

Like tail(1) which is part of coreutils?

|  however if that functionality was built-in to systemd, just as it is
| already built-in to depinit, i.e. if the services which were fired off
| foreground-style by systemd could have their stdin, stdout and stderr
| redirected to applications/scripts, as specified by command-line
| options to systemd...

command line options to systemd doesn't make any sense, it's an init
replacement, not a wrapper around single daemons.

| > The systemd option of creating sockets before executing services that listen
| > to them seems to offer the potential of more significant boot performance
| > benefits than just starting things in parallel.
| 
|  that's got my eyebrows raised - how the heck does _that_ work?  i'm
| both surprised and intrigued.
| 
|  ok, darn it - systemd seems to be a really bad name choice: google
| search comes up with "Systeme D", and also systemd on windows??

http://www.freedesktop.org/wiki/Software/systemd is hit number four or
five for it on google.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrudbti5@qurzaw.linpro.no

Re: Re (2): lilo removal in squeeze (or, "please test grub2")

[Russell Coker]

On Wed, 26 May 2010, Stephen Powell  wrote:
> You're missing the point.  The main selling point to management
> is that Linux is free.  If they have to buy new backup software
> in order to accommodate Linux' backup requirements, that will
> kill it on the spot.  Whatever boot loader I use must not
> require new backup software or impose special backup requirements.

One of the advantages of Linux is that you are not forced to do things the way 
that the distribution vendor packages it.

You can take the last lilo package that gets uploaded, build it and put it in 
your own apt repository, and then support it for your own users.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201006052230.21682.russ...@coker.com.au

Bug#584689: ITP: justniffer -- TCP packet sniffer

[Andrea Colangelo]

Package: wnpp
Severity: wishlist
Owner: Andrea Colangelo 


* Package name: justniffer
  Version : 0.5.7
  Upstream Author : Oreste Notelli 
* URL : http://justniffer.sourceforge.net/
* License : GPL
  Programming Lang: C++
  Description : TCP packet sniffer

justniffer is a tcp packet sniffer. It can log network traffic in a
'standard' (web server like) or in a customized way. It can also log
response times, useful for tracking network services performances
(e.g. web server, application server, etc.) and capture http traffic
content.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100605164749.7484.86728.report...@starfleet

Re: pid file security

[Fernando Lemos]

On Sat, Jun 5, 2010 at 7:59 AM, Luke Kenneth Casson Leighton
 wrote:
>  okaaay, riight.  so.  ah ha.  it makes things quicker... by avoiding
> starting the services _entirely_ :)

It goes beyond that. Instead of program A depending on B being done
initializing so that it can connect to B's socket, for example, A can
be initialized right away and it'll block when it needs to use B's
socket until B is done initializing. This is faster because A and B
can be started at the same time even though A depends on something
provided by B.

>  second: assuming that systemd is _only_ capable of starting up
> services [as an inetd replacement] via redirecting stdin/stdout to
> TCP/UDP/other sockets, that still places depinit as being more capable
> than systemd because you have the option, in depinit, of:
>
>  * running a service "unmonitored" i.e. a la sysv init
>  * running a services "foreground-connected" i.e. auto-restarted etc.

Well, systemd does have sysv-like compatibility (in fact it even
parses LSB headers and starts sysv scripts in parallel, unlike
upstart). I believe that in that mode it does not monitor the
processes, but I'm not sure.

Now regarding auto-restarting services as they fail, I believe that's
at least planned. Since systemd can monitor services with ease, my
guess is that auto-restarting shouldn't be a big deal.

I'm quite excited about systemd, I think the potential is there. Most
mainstream distros have already commited to upstart though, so I can
see why it could fail despite looking like a great alternative.
Another major issue is lack of cross-platform support, as it depends
on Linux specifics such as cgroups, and this is a big drawback for
Debian as we have Hurd and kFreeBSD...

More info on systemd in this lengthy blog post:

http://0pointer.de/blog/projects/systemd.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktim-lsngdcjqj8tqulxz7rd4dlu66dvq6kcyg...@mail.gmail.com

how to help end-users to increase the life-time of their SSDs

[Christoph Anton Mitterer]

Hi folks.

I recently got my first SSD payed by my university and, even though
modern SSDs seem to have smart wear leveling algorithms and more and
more parts of kernel/userspace support TRIM, I was thinking about what
one can do to improve its lifetime.

The most obvious things I found were:
- /tmp as tmpfs
- optionally /var/tmp as tmpfs
- moving my browser's Cache to some tmpfs (either it's own) or simply
to /tmp


Perhaps there are more good ideas others here might have (and add), but
I'm writing because I thought how we could best bring such changes to
the end-users?

- Just providing some document with tips and howtos?
This has at least the disadvantage that many people probably never read
it, and that we cannot "fix" things which are no longer necessary (e.g.
if /tmp is on tmpfs, we do not have to clean it any longer.. ok bad
example, as we should keep this one probably as it happens anyway on
startup, not on shutdown IIRC).

- Providing a separate package, which does the necessary stuff e.g.
modifying /etc/fstab or adding own initscripts that check whether an SSD
is used, and if so mount /tmp on tmpfs? And if the users wished to do
so, also /var/tmp?
Such a package could still provide a README, dealing with things the
package cannot do automatically (e.g. the iceweasel cache directory)

- Integrate such functionality in existing packages?



Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#584718: ITP: nesc -- A Programming Language for Deeply Networked Systems

[Razvan Musaloiu-E.]

Package: wnpp
Severity: wishlist
Owner: "Razvan Musaloiu-E." 

* Package name: nesc
  Version : 1.3.1
  Upstream Author : David Gay 
* URL : http://http://nescc.sourceforge.net
* License : GPL
  Programming Lang: C
  Description : A Programming Language for Deeply Networked Systems

nesC (pronounced "NES-see") is an extension to the C programming language
designed to embody the structuring concepts and execution model of TinyOS.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100605043849.25475.68466.report...@supermicro

Bug#584723: ITP: libhdhomerun -- Configuration utility for Silicon Dust HD HomeRun

[Francois Marier]

Package: wnpp
Severity: wishlist
Owner: Francois Marier 

* Package name: libhdhomerun
  Version : 20100213
  Upstream Author : Silicondust Engineering Ltd. 
* URL : http://www.silicondust.com/downloads/linux
* License : GPL
  Programming Lang: C
  Description : Configuration utility for Silicon Dust HD HomeRun

 This package supports the Silicon Dust HDHomeRun.
 The HDHomeRun is a networked, two tuner digital TV tuner compatible with 
 MythTV, SageTV, and VLC.
 .
 This utility can be used for:
  * Discovering your tuner location and name
  * Gathering tuner settings
  * Setting tuner setting
  * Performing scans
  * Performing firmware upgrades

This has been in Ubuntu since 2007 and my package will be based on that
work.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100606020522.8017.37686.report...@isafjordur.dyndns.org

A Look In the Mirror: Attacks on Package Managers

[Erik de Castro Lopo]

Hi All,

Did anyone see this paper:

A Look In the Mirror: Attacks on Package Managers
http://www.cs.arizona.edu/~jhh/papers/ccs08.pdf

It suggests that anyone who has control of a mirror can cause client
machines to install software created by the attacker or install an
outdated version of a package with a vulnerability the attacker knows
how to exploit.

Is anyone in Debian working on a response to this issue.

Cheers,
Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100606122827.acb09dd5.mle+deb...@mega-nerd.com

Possible Mass Bug Filing: String Exceptions Removed in Python 2.6

[Scott Kitterman]

As was recently discussed on debian-python:

http://lists.debian.org/debian-python/2010/05/msg00111.html

String exceptions are no longer supported at all in Python 2.6.  Since this is 
the Python version planned to be the default in Squeeze, packages still using 
them should be fixed.  String exceptions have never worked reliably or been a 
good idea.  It is time for them to go.

A couple of weeks ago, Jakub Wilk noticed this issue and prepared both a DD 
list of affected packages and the grep output that was used to detect 
potentially affected packages.  I know some of these packages have been fixed 
already.  Please reply to debian-python with fix reports or reports of false 
positives.

http://people.debian.org/~jwilk/tmp/string-exceptions.ddlist

http://people.debian.org/~jwilk/tmp/string-exceptions.log

Without examining each package in detail, it's difficult to know the impact of 
this error on each package.  I expect to file the bugs at normal severity and 
leave it to maintainers to adjust it up or down.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201006052243.28438.deb...@kitterman.com

Re: A Look In the Mirror: Attacks on Package Managers

[James Vega]

On Sun, Jun 06, 2010 at 12:28:27PM +1000, Erik de Castro Lopo wrote:
> Did anyone see this paper:
> 
> A Look In the Mirror: Attacks on Package Managers
> http://www.cs.arizona.edu/~jhh/papers/ccs08.pdf

See the previous discussion that already happend on this list:
http://lists.debian.org/487753dc.5020...@cox.net

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: A Look In the Mirror: Attacks on Package Managers

[Erik de Castro Lopo]

James Vega wrote:

> On Sun, Jun 06, 2010 at 12:28:27PM +1000, Erik de Castro Lopo wrote:
> > Did anyone see this paper:
> > 
> > A Look In the Mirror: Attacks on Package Managers
> > http://www.cs.arizona.edu/~jhh/papers/ccs08.pdf
> 
> See the previous discussion that already happend on this list:
> http://lists.debian.org/487753dc.5020...@cox.net

Ok, from this message:
 
http://lists.debian.org/debian-devel/2008/07/msg00868.html

A big thank you to the various Debian security people who have helped
answer questions and verify information for us recently. I believe most
of the issues we disclosed are in discussion and will be addressed.

Anyone have any idea where this discussion is beging held and what
exactly is being addressed?

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100606125731.7c488f04.er...@mega-nerd.com

Bug#584727: ITP: scim-googlepinyin -- Google Pinyin IM engine module for SCIM

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: scim-googlepinyin
  Version : 20100606
  Upstream Author : Kov Chai 
* URL : http://code.google.com/p/scim-googlepinyin/
* License : Apache 2.0
  Programming Lang: C
  Description : Google Pinyin IM engine module for SCIM

Long description:
SCIM (Smart Common Input Method) is an input method (IM) platform.

scim-googlepinyin tries to bring the open source Google pinyin IME for
Android to GNU/Linux. And customize it to fit the need on regular
desktop instead of on mobile device by following Google Pinyin on
Windows.

This port is almost a line-by line translation from Java to C++. It's
still under development. And it needs more testing and bug fixing for
sure.

Maintainer note:
As the author describes his own work as being experimental, my
intention is to first upload to experimental (makes sense, no?), until
the author himself confirms that it works ok, and after my Chinese
wife tests it for a long time in her Ubuntu laptop. For the few times
I could test it, googlepinyin seems perfectly stable, but I still want
to hear from the author and test it, before this package reaches SID
or testing.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100606032105.4160.2136.report...@buzzig.gplhost.com

Re: A Look In the Mirror: Attacks on Package Managers

[Michael Gilbert]

On Sun, 6 Jun 2010 12:28:27 +1000 Erik de Castro Lopo wrote:

> Hi All,
> 
> Did anyone see this paper:
> 
> A Look In the Mirror: Attacks on Package Managers
> http://www.cs.arizona.edu/~jhh/papers/ccs08.pdf
> 
> It suggests that anyone who has control of a mirror can cause client
> machines to install software created by the attacker or install an
> outdated version of a package with a vulnerability the attacker knows
> how to exploit.

All of the issues raised in this paper can be mitigated by a "proactive"
user.  Malicious mirror activity can be detected by paying attention to
debsecan and the security tracker [0].  debsecan displays all known
vulnerable packages on a particular system, and the security tracker
displays all known vulnerable packages.  Differences between the two for
a period longer than about a week would be a sign that the mirror is
intentionally holding back vulnerable packages.

Of course the major flaw with this statement is that there aren't a
whole these "proactive" users.  However, if there are enough, some will
spot the activity, and raise concern, which will ultimately protect
others when the evil mirror is shut down.

Mike

[0] http://security-tracker.debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100606003753.f701e457.michael.s.gilb...@gmail.com

Re: A Look In the Mirror: Attacks on Package Managers

[Erik de Castro Lopo]

Michael Gilbert wrote:

> Of course the major flaw with this statement is that there aren't a
> whole these "proactive" users.  However, if there are enough, some will
> spot the activity, and raise concern, which will ultimately protect
> others when the evil mirror is shut down.

Ok, my concerns over this have been assuaged somewhat. However, I still
think that having the package management software more secure by default
might still be better than relying on proactive users.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100606145810.2ea1ad40.er...@mega-nerd.com

Bug#584729: ITP: libpackage-stash-perl -- Perl module providing routines for manipulating stashes

[Ansgar Burchardt]

Package: wnpp
Severity: wishlist
Owner: Ansgar Burchardt 

* Package name: libpackage-stash-perl
  Version : 0.03
  Upstream Author : Jesse Luehrs 
* URL : http://search.cpan.org/dist/Package-Stash/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module providing routines for manipulating stashes

 Manipulating stashes (Perl's symbol tables) is occasionally necessary, but
 incredibly messy, and easy to get wrong. Package::Stash hides all of that
 behind a simple API.

This module is required by new upstream releases of libclass-mop-perl and
libnamespace-clean-perl.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100606050209.11121.73643.report...@marvin.43-1.org

Re: A Look In the Mirror: Attacks on Package Managers

[Russ Allbery]

Erik de Castro Lopo  writes:
> Michael Gilbert wrote:

>> Of course the major flaw with this statement is that there aren't a
>> whole these "proactive" users.  However, if there are enough, some will
>> spot the activity, and raise concern, which will ultimately protect
>> others when the evil mirror is shut down.

> Ok, my concerns over this have been assuaged somewhat. However, I still
> think that having the package management software more secure by default
> might still be better than relying on proactive users.

Note that the only attack described in that paper that's viable against
Debian is the one in which security updates are suppressed on a particular
mirror and the attacker then takes advantage of unpatched software.  There
isn't any way for a mirror operator to insert modified or additional
packages given how Debian's repository signing system works, with the
possible exception of the initial bootstrap of a new installation unless
the user doing the install manually establishes an initial chain of trust
by verifying the signature of the installation image.

There was some discussion of periodically resigning the security archive
even if there are no updates so that package managers could warn if more
than X days had gone by without an update to the security archive
signatures.  I don't know if anyone has concrete plans to implement that.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ljas7mqs@windlord.stanford.edu

Re: A Look In the Mirror: Attacks on Package Managers

[Fernando Lemos]

On Sun, Jun 6, 2010 at 1:37 AM, Michael Gilbert
 wrote:
> All of the issues raised in this paper can be mitigated by a "proactive"
> user.  Malicious mirror activity can be detected by paying attention to
> debsecan and the security tracker [0].  debsecan displays all known
> vulnerable packages on a particular system, and the security tracker
> displays all known vulnerable packages.  Differences between the two for
> a period longer than about a week would be a sign that the mirror is
> intentionally holding back vulnerable packages.
>
> Of course the major flaw with this statement is that there aren't a
> whole these "proactive" users.  However, if there are enough, some will
> spot the activity, and raise concern, which will ultimately protect
> others when the evil mirror is shut down.

Agreed.

I'd like to point out that since we sign root metadata, it's
impossible to keep some packages outdated (say, daemons facing the
internet) while others are up-to-date. What this means is that a
replay or freeze attack is very unlikely to go unnoticed. Lots of
packages being downgraded, no updates for too long, things like that
stand out. If an admin doesn't notice that, I find it unlikely that he
or she will notice a stale mirror warning either.

Moreover, as people have said already, stable is safe because security
updates come directly from security.debian.org, not from mirrors. The
remaining issues I see are:

1. Man-in-the-middle attacks between clients and security update servers
2. Denial-of-service attacks to the security updates infrastructure
3. No trusted servers for security updates for testing and unstable

Using HTTPS for the security update infrastructure could solve #1, but
not much can be done about #2 (though such an attack would be
Hollywood-esque in scale).

Now if we had a timestamp in the root metadata updated on a daily
basis, that would solve #1 and #3 (or anything else related to replay
attacks), and it doesn't sound too hard to implement (of course, talk
is cheap). #2 is not quite under our control.

Another idea would be actively comparing mirrors to make sure evil or
dead mirrors are removed from our list of mirrors (if that isn't the
case already). Not much can be done if the end user isn't being
notified, though. Coupled to that, maybe some sort of PKI could make
it possible to revoke the hability of the mirror to advertise itself
as a trusted, up-to-date mirror.

The bottomline seems to be that stable is safe enough, whereas if you
use something else you're on your own as usual, but I believe we can
improve this situation.

I'm neither a security guy nor a Debian infrastructure guy, so please
take my words with a grain of salt.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktin08k1oam2-qbnqqmununf6_fvmx6-_7mjyg...@mail.gmail.com

Re: A Look In the Mirror: Attacks on Package Managers

[Ansgar Burchardt]

Russ Allbery  writes:

> There was some discussion of periodically resigning the security archive
> even if there are no updates so that package managers could warn if more
> than X days had gone by without an update to the security archive
> signatures.  I don't know if anyone has concrete plans to implement that.

The Release file in the repository has now a Valid-Until field that
invalidates the repository after some time without updates. This can be
used to detect a mirror provided outdated packages.

I am not sure whether APT checks this or not. I hope it does.

Regards,
Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4qc90bc@marvin.43-1.org

Re: how to help end-users to increase the life-time of their SSDs

[Michael Tokarev]

06.06.2010 02:13, Christoph Anton Mitterer wrote:

Hi folks.

I recently got my first SSD payed by my university and, even though
modern SSDs seem to have smart wear leveling algorithms and more and
more parts of kernel/userspace support TRIM, I was thinking about what
one can do to improve its lifetime.

The most obvious things I found were:
- /tmp as tmpfs
- optionally /var/tmp as tmpfs


Not an answer to your original question, just a not-so-random observation.
/var/tmp is declared by LFS as "temporary storage that persists across
reboots".  It wont be this way if it's on tmpfs obviously.


- moving my browser's Cache to some tmpfs (either it's own) or simply
to /tmp


And browser cache is something that is not very useful if it does not
survive a reboot.

But granted, it all depends on the frequency of reboots.  If reboots
never happen, everything, i.e. whole filesystem, can be on tmpfs.
So... YMMV :)

/mjt


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c0b4024.6070...@msgid.tls.msk.ru