Re: Bug#540215: Introduce dh_checksums

[Frank Lin PIAT]

On Mon, 2010-03-08 at 19:57 -0800, Russ Allbery wrote:
> Joey Hess  writes:
> > Russ Allbery wrote:
> 
> >> It's also always worth bearing in mind that while a really good
> >> attacker can do all sorts of complex things that make them very hard to
> >> find, most attackers are stupid and straightforward.
> 
> > It's stupid and straightforward to install /usr/local/bin/ls. debsums
> > will not detect it.
> 
> True.  Adding new binaries is, in my experience, more common than
> modifying binaries already on the system.
> 
> I don't really mean to be arguing for debsums as a security mechanism,
> more just commenting on the general question.  I'm on the side that thinks
> that debsums isn't a horribly useful direction to go for full-blown
> intrusion detection, and that for what it's really useful for right now
> MD5 remains entirely adequate.

How do people know which binaries are still pristine, so they can keep
looking for issues elsewhere? (like added binaries and modified and
insecure configuration file...)
Not everyone uses aide (popcon: 0.49%).

What solution do we have for Joe user (whom did not install aide)?
What's the agenda for squeeze and squeeze+1?
Who is actually stepping up to do the Job?

Please, let's do the easy move *now* for Squeeze, using shasums, and go
ahead later with an even better solution. This transition can be quick,
it will remain quite unnoticed by people that aren't interested, but it
will be appreciated by people who want to use it.

Regards,

--
Franklin Piat  | The better is the enemy of the good. (Voltaire)




-- 
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/1268123295.21347.12099.ca...@solid.paris.klabs.be

Re: Proposed removal of arch-perl (libarch-perl)

[Alex Muntada]

+ Mikhael Goikhman :

> I think README gives a handful of hints about the package. Anyway, in
> the devel branch (managed under tla, that is mentioned in README too)
> all tests should now pass even without tla or baz installed.
> I.e.:  TLA=/bin/false make test

IIRC, having Makefile.PL exit a non-zero value should make all CPAN
smokers ignore the module (no FAIL nor SKIP). Since it should be
quite straight-forward to check if tla is available on the system and
there's no point on installing Arch module unless tla is available, failing
early in Makefile.PL is a Good Thing, IMHO.

HTH

-- 
Alex Muntada 
http://alexm.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/35064d941003090333o5bebf853w67e50c82042a4...@mail.gmail.com

Re: Bug#540215: Introduce dh_checksums

[Jean-Christophe Dubacq]

On 09/03/2010 14:24, Bernhard R. Link wrote:

> 
> It it's that straight forward, please help with the cruft package.
> Last time I looked (several years ago) it was severly limited by that
> problem (there not being a way to know which files should be there and
> which not).
> 
> I personally think without something in this direction, intrusion
> detection based on file lists is not really possible.

I for one pledge the addition of a dpkg-register (or dpkg --register or
anything), bound with dpkg, that would allow maintainers to specify that
a file belongs to their package (it could be managed through postinsts,
via ucf...) The number of files under /etc that belong to no package (in
the sense of dpkg -S) makes it very hard to keep a clean system.


-- 
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/4b964e0b.3060...@free.fr

Re: Bug#540215: Introduce dh_checksums

[Harald Braumann]

On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote:
> Russ Allbery wrote:
> > It's also always worth bearing in mind that while a really good attacker
> > can do all sorts of complex things that make them very hard to find, most
> > attackers are stupid and straightforward.
> 
> It's stupid and straightforward to install /usr/local/bin/ls. debsums
> will not detect it.

And it's as straightforward to find files which don't belong to any
package and have some other means in place to check locally generated
files.

If I understand you correctly, you argue that one would need some IDS
anyway to cover all files, and that could then be used also to verify
package files. Therefore making file signatures in packages
superfluous. I think I could agree with that. On the other hand, I
tend to keep /usr/local clean and create packages for for home-grown
software. If you do this consistently, you'd get a system where you
could verify all files without additional software (modulo the script
that checks for surplus files).

More important  would be package signatures, anyway,  because
currently there is no way to verify a package. I work with
testing/unstable a lot and often I have deb files lying around are
not in any Release, so there is no way of verifying them.

harry


-- 
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/20100309125920.gc15...@nn.nn

Re: Proposed removal of arch-perl (libarch-perl)

[Mikhael Goikhman]

On 09 Mar 2010 12:33:44 +0100, Alex Muntada wrote:
> 
> + Mikhael Goikhman :
> 
> > I think README gives a handful of hints about the package. Anyway, in
> > the devel branch (managed under tla, that is mentioned in README too)
> > all tests should now pass even without tla or baz installed.
> > I.e.:  TLA=/bin/false make test
> 
> IIRC, having Makefile.PL exit a non-zero value should make all CPAN
> smokers ignore the module (no FAIL nor SKIP). Since it should be
> quite straight-forward to check if tla is available on the system
> and there's no point on installing Arch module unless tla is
> available, failing early in Makefile.PL is a Good Thing, IMHO.

This is a reasonable approach. On the other hand it is a pure perl
code that may be installed before installing tla (or its equivalent),
and you may even point to different backend installations at run-time.
In addition, half of the functionality does not depend on presense of
tla. Also, the code has explicit support for perl 5.005, 5.6, 5.8+
and it would be interesting to see whether it is actually true.

So the 0.5.2 release from yesterday tries a different approach, to
skip the relevant tests with "No functional arch backend" reason.

Regards,
Mikhael.

-- 
perl -e 'print+chr(64+hex)for+split//,d9b815c07f9b8d1e'


-- 
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/20100309142118.gb21...@otaku

Re: Bug#540215: Introduce dh_checksums

[Bernhard R. Link]

* Harald Braumann  [100309 13:59]:
> On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote:
> > Russ Allbery wrote:
> > > It's also always worth bearing in mind that while a really good attacker
> > > can do all sorts of complex things that make them very hard to find, most
> > > attackers are stupid and straightforward.
> >
> > It's stupid and straightforward to install /usr/local/bin/ls. debsums
> > will not detect it.
>
> And it's as straightforward to find files which don't belong to any
> package and have some other means in place to check locally generated
> files.

It it's that straight forward, please help with the cruft package.
Last time I looked (several years ago) it was severly limited by that
problem (there not being a way to know which files should be there and
which not).

I personally think without something in this direction, intrusion
detection based on file lists is not really possible.

Hochachtungsvoll,
Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth


-- 
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/20100309132432.ga30...@pcpool00.mathematik.uni-freiburg.de

Bug#573162: ITP: django-picklefield -- Pickled object field for Django

[Fladischer Michael]

Package: wnpp
Severity: wishlist
Owner: Fladischer Michael 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: django-picklefield
  Version : 0.1
  Upstream Author : Shrubbery Software 
* URL : http://github.com/shrubberysoft/django-picklefield
* License : MIT
  Programming Lang: Python
  Description : Pickled object field for Django

django-picklefield provides an implementation of a pickled object field for the 
Django framework.  Such fields can contain any picklable objects.


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

iEYEARECAAYFAkuWToEACgkQeJ3z1zFMUGbNIQCdEmW3mbDfahDmhZkNQlgEXemw
FuwAniZWsGuo/c/JmN/dLfMpgUc3FszH
=ziD/
-END PGP SIGNATURE-



-- 
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/20100309133457.11635.79356.report...@ossus.home.fladi.at

Re: Bug#540215: Introduce dh_checksums

[Jakub Wilk]

* Peter Samuelson , 2010-03-09, 08:21:

[Frank Lin PIAT]

Why is that everyone seems to move away from MD5?


That's the $64000 question, isn't it?  There seems to be this knee-jerk
reaction to all things md5, "OH NOES, MD5 is broken!  Therefore it must
be replaced in every possible use, never mind whether any particular
use has anything to do with malicious attackers."

Strange that rsync seems to have escaped this madness, nobody has been
frantically calling for it to migrate to something more "up to date"
than MD4.  Which, IIRC, is just as "broken".  I guess the masses must
have realized, in a way they usually do not, that sometimes an
integrity check is just an integrity check.


FYI:
$ zgrep MD5 /usr/share/doc/rsync/changelog.gz
- Protocol 30 now uses MD5 checksums instead of MD4.

That said, I totally agree with you.

--
Jakub Wilk


signature.asc
Description: Digital signature

Bug#573149: ITP: merlin -- Module for Effortless Redundancy and Loadbalancing In Nagios

[Hendrik Frenzel]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: merlin
Version: 0.6.7~b1
Upstream Author: op5 AB
URL: http://www.op5.org/community/projects/merlin
License: GPL-2
Description: The Merlin project, or Module for Effortless Redundancy
and Loadbalancing In
 Nagios, for setting up distributed Nagios installations and allowing Nagios
 processes to exchange information directly.




-- 
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/4b962f8c.8080...@scunc.net

Re: Bug#540215: Introduce dh_checksums

[Peter Samuelson]

> On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
> > If we take option 2, SHA256 offers no benefits over MD5 and just takes
> > longer to compute.

[Frank Lin PIAT]
> Why is that everyone seems to move away from MD5?

That's the $64000 question, isn't it?  There seems to be this knee-jerk
reaction to all things md5, "OH NOES, MD5 is broken!  Therefore it must
be replaced in every possible use, never mind whether any particular
use has anything to do with malicious attackers."

Strange that rsync seems to have escaped this madness, nobody has been
frantically calling for it to migrate to something more "up to date"
than MD4.  Which, IIRC, is just as "broken".  I guess the masses must
have realized, in a way they usually do not, that sometimes an
integrity check is just an integrity check.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20100309142149.gp18...@p12n.org

Re: libgcrypt brain dead?

[Simon Josefsson]

Brian May  writes:

> Or is there another way?

There is the option of changing GnuTLS to use something other than
libgcrypt.  There are APIs for doing this dynamically in GnuTLS, and if
that is not sufficient (if you want to avoid linking to libgcrypt
entirely) we could also support e.g. GNU Nettle as the crypto library.
However some parts may be missing from GNU Nettle, e.g., entropy
gathering functionality, so that would have to be re-implemented.  This
option requires that someone contribute this code to GnuTLS, of course.

/Simon


-- 
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/87lje1pqub@mocca.josefsson.org

dsniff is dead, long life to dsniff

[Luciano Bello]

Please, CC me (my usual account is off-line momentarily)

Hi all,
I'm the dsniff[1] maintainer, which is a pretty dead project[2]. Dug
Song (the upstream) is putting his efforts in rewrite the project in
python[3], which is quite limited compared to the previous one.
The question is: should I package this new version as a replacement
of the previous one, even one there is a big reduction in the feature
list? Or, should I create a new package (let's say, python-dsniff) and
RM dsniff?

luciano

[1] http://packages.qa.debian.org/d/dsniff.html
[2] http://www.monkey.org/~dugsong/dsniff/
[3] http://code.google.com/p/dsniff/


-- 
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/d2a184d11003090801i3e92bfaav7cc1692f33cee...@mail.gmail.com

Re: Bug#540215: Introduce dh_checksums

[Peter Samuelson]

[Frank Lin PIAT]
> Please, let's do the easy move *now* for Squeeze, using shasums, and
> go ahead later with an even better solution.

Drawbacks: more CPU time on build daemons, slightly larger binary
packages to download, and some disruption when we're trying to get a
release out the door.

Advantages: ... umm ... warm fuzzy feeling that we aren't relying on
that old stupid broken MD5 thing that is so out of fashion these days
among the cognoscenti?

If you really want to use /var/lib/dpkg/info/pkg.*sums files for any
purpose other than detecting non-malicious corruption, obviously you
need _either_ some form of package signatures, _or_ a server akin to
http://packages.debian.org/changelogs/ for serving checksums from a
more trusted source.  And of course if you have that sort of server
support anyway - why not just calculate those sha16384 sums on the
server, with no change to the debs at all?

Peter


-- 
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/20100309165059.gr18...@p12n.org

Re: Bug#540215: Introduce dh_checksums

[Joey Hess]

Harald Braumann wrote:
> On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote:
> > It's stupid and straightforward to install /usr/local/bin/ls. debsums
> > will not detect it.
> 
> And it's as straightforward to find files which don't belong to any
> package and have some other means in place to check locally generated
> files.

I don't want to get dragged into continuing to provide counterexamples,
but it's also fairly easy to modify a file in /etc to provide a
backdoor, such that neither debsums nor cruft will notice it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#540215: Introduce dh_checksums

[Manoj Srivastava]

On Tue, Mar 09 2010, Jean-Christophe Dubacq wrote:

> On 09/03/2010 14:24, Bernhard R. Link wrote:
>
>> 
>> It it's that straight forward, please help with the cruft package.
>> Last time I looked (several years ago) it was severly limited by that
>> problem (there not being a way to know which files should be there and
>> which not).
>> 
>> I personally think without something in this direction, intrusion
>> detection based on file lists is not really possible.
>
> I for one pledge the addition of a dpkg-register (or dpkg --register or
> anything), bound with dpkg, that would allow maintainers to specify that
> a file belongs to their package (it could be managed through postinsts,
> via ucf...) The number of files under /etc that belong to no package (in
> the sense of dpkg -S) makes it very hard to keep a clean system.

For what it is worth, ucf can also tell dpkg about the files and
 hashes  that it manages (it already stores the data, all that has to be
 added is calls to the hypothetical dpkg-register).

manoj
-- 
Oliver's Law: Experience is something you don't get until just after you
need it.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


-- 
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/87pr3dbib2@anzu.internal.golden-gryphon.com

Debian Package

[Jake]

Hello,

I was creating a Debian package and after it install I would like it to
prompt the user to reboot the computer, is there anyway to do this?

Thank You,
Jacob Fernandes


-- 
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/1268157151.5164.1.ca...@jake-laptop

Re: Debian Package

[Patrick Matthäi]

Am 09.03.2010 18:52, schrieb Jake:

Hello,

I was creating a Debian package and after it install I would like it to
prompt the user to reboot the computer, is there anyway to do this?


The right way here is to use debconf for it.
But why should it be needed to reboot the computer after this?

I am feeling myself remembered to windows systems >.<

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/


--
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/4b968fe3.4040...@debian.org

Re: dsniff is dead, long life to dsniff

[Carlos Galisteo]

On Tue, Mar 9, 2010 at 5:01 PM, Luciano Bello  wrote:

>        The question is: should I package this new version as a replacement
> of the previous one, even one there is a big reduction in the feature
> list? Or, should I create a new package (let's say, python-dsniff) and
> RM dsniff?

 As an occasional dsniff user, I'd rather keep the full (old) version
in Debian while the new one is incomplete.

 If the new package is a Python module it'd be nice to have it also in
Debian in order to familiarize ourself with it, but IMHO the original
one should not be removed until the new one is full-featured.

 Regards.

-- 
---
Carlos Galisteo 
GPG keys & fingerprints:
0x8E0076E9 -> 939E 3D10 EAA2 A972 3AF2  E25C 26B7 D8E3 8E00 76E9
0x69ADBE65 >  F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65
---


--
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/de85d2bf1003091016o46be651coc1fd2b8052339...@mail.gmail.com

Re: Debian Package

[brian m. carlson]

On Tue, Mar 09, 2010 at 12:52:31PM -0500, Jake wrote:
> Hello,
> 
> I was creating a Debian package and after it install I would like it to
> prompt the user to reboot the computer, is there anyway to do this?

Except in very limited circumstances, there should be no need to reboot
the computer after installing a package.  The only exception I can think
of is something related to the kernel; in general, root should be aware
that a reboot is required to make that functionality work, but may want
to defer it indefinitely (for example, on a server).

So yes, the right way to do this is debconf, but what you want to do is
probably the wrong thing.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#540215: Introduce dh_checksums

[Harald Braumann]

On Tue, Mar 09, 2010 at 10:50:59AM -0600, Peter Samuelson wrote:
> 
> [Frank Lin PIAT]
> > Please, let's do the easy move *now* for Squeeze, using shasums, and
> > go ahead later with an even better solution.
> 
> Drawbacks: more CPU time on build daemons, slightly larger binary
> packages to download, and some disruption when we're trying to get a
> release out the door.
> 
> Advantages: ... umm ... warm fuzzy feeling that we aren't relying on
> that old stupid broken MD5 thing that is so out of fashion these days
> among the cognoscenti?
> 
> If you really want to use /var/lib/dpkg/info/pkg.*sums files for any
> purpose other than detecting non-malicious corruption, obviously you
> need _either_ some form of package signatures, _or_ a server akin to
> http://packages.debian.org/changelogs/ for serving checksums from a
> more trusted source.  And of course if you have that sort of server
> support anyway - why not just calculate those sha16384 sums on the
> server, with no change to the debs at all?

See, you don't need a server. You just ship a signature over the hash
files. Easy as that. Of course the hashes would neet to be something more
secure than md5, for that warm fuzzy feeling that in two years time
not every script kiddy can mount hash attacks on their home computer.

harry


-- 
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/20100309183541.ga25...@nn.nn

Re: Bug#572374: please consider Section: Education

[Ana Guerrero]

On Tue, Mar 09, 2010 at 08:36:24AM +0100, Andreas Tille wrote:
> While I agree in principle with this attempt there might be a lot of
> packages which fit into Science *and* Education section.  The sections
> approach in Debian is weak in the way that a package can only be put in
> one section.  The alternatives are DebTags and the Blends tasks.  If you
> compare the tasks of Debian Science[1] and Debian Edu[2] in the
> "typical" sciences Astronomy, Chemistry, Electronics, Mathematics and
> Physics you will realise the problem.
>

There will be always packages that fit in several sections and the maintainer
will have to pick the best one. About the alternatives you mention, something
was hinted in this email [1], but in the meantime all the educative apps 
deserve somethig better than "misc".

[1] http://lists.debian.org/debian-devel-announce/2009/03/msg00010.html

> So I agree that education related applications from section misc should
> definitely get a better home.

Yes :)

Ana


-- 
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/20100309181519.ga26...@pryan.ekaia.org

Bug#573206: ITP: png++ -- C++ interface to the PNG library

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: png++
  Version : 0.2.3
  Upstream Author : Alex Shulgin 
* URL : http://savannah.nongnu.org/projects/pngpp/
* License : BSD
  Programming Lang: C++
  Description : C++ interface to the PNG library

PNG++ aims to provide simple yet powerful C++ interface to libpng, the
PNG reference implementation library.



-- 
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/20100309185401.20565.69441.report...@localhost.localdomain

Re: libgcrypt brain dead?

[Vincent Fourmond]

Brian May wrote:
> 2. libgcrypt drops root privileges if called setuid on the assumption
> the only reason the program is setuid root is so it can lock memory.
> 
> Unfortunately this breaks every setuid program tat uses PAM when PAM
> is configured to use ldap and ldap is configured to use gnutls,
> because gnutls uses gcrypt.

  An example is pmount, who sometime calls cryptsetup itself relying on
gcrypt.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551540

  In that case, the workaround is to call cryptsetup as root, but that
doesn't sound right and could lead to more problems...

  Why gcrypt doesn't leave up to the caller to deal with dropping
privileges ? The not-dropping-privileges hack mentioned by Werner Koch
in #566351 should be fine enough...

Vincent

-- 
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/

Comme dit mon tonton: plus on est de cons, plus ça se voit !
 -- La Tordue, Où va-t-on

Vincent, listening to Planet Telex (Radiohead)


-- 
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/4b96a522.7030...@debian.org

Re: Bug#540215: Introduce dh_checksums

[Anthony Towns]

Hey Russ,

On Tue, Mar 9, 2010 at 13:57, Russ Allbery  wrote:
> Joey Hess  writes:
>> Russ Allbery wrote:
>>> It's also always worth bearing in mind that while a really good
>>> attacker can do all sorts of complex things that make them very hard to
>>> find, most attackers are stupid and straightforward.
>> It's stupid and straightforward to install /usr/local/bin/ls. debsums
>> will not detect it.
> True.  Adding new binaries is, in my experience, more common than
> modifying binaries already on the system.
> I don't really mean to be arguing for debsums as a security mechanism,
> more just commenting on the general question.

So what's the goal here? Basic integrity checking by defending against
random corruption due to occassional hardware, software or admin
errors? Or an additional security layer verifying that the installed
system software is still exactly what it was intended to be?

(Or, I guess, a third option would be that it's just some security
theatre to make people feel more comfortable about their system's
integrity, without actually adding any technical guarantees.)

For basic integrity checking, I'm finding the dpkg patch I posted the
other day works fairly nicely -- I've reinstalled the handful of
packages that don't provide md5sums files so dpkg would generate the
hashes file for me, and now I've got hashes for every package on my
system, without having to worry about policy getting changed or
packages getting reuploaded, or having to worry about bugs like any
random packages I might use not following the new policy.

And now that I actually look at debsums, rather than just checking
with md5sum -c directly, I see debsums already gets invoked by apt by
default to ensure that there's an md5sums file for every package. And
that's been there for a fair while, based on Bug#132767.

If the idea is just to catch a wide swathe of accidental errors,
doesn't it make sense to stick with md5 as being cheap and unlikely to
have accidental collisions, do the md5sum generation in either apt or
dpkg to guarantee it's done for all installed packages, and leave it
at that? That means we could get rid of a bunch of policy and code
from package build scripts, which seems like it could only be a good
thing; and it also seems pretty easy to do for squeeze (since it's
already done as far as apt is concerned, and there's a patch for dpkg
if desired, and no other packages need to be changed).

The only drawback seems to be that you end up verifying what was
actually installed, and that might differ from verifying what was
meant to be installed in the event that the deb you're installing gets
corrupted while you're reading it, despite having previously passing
its own secure hash check.

OTOH, if the idea is to do more than just basic integrity checking of
dpkg-installed files, to aid in detection of and recovery from
malicious/deliberate changes, it seems like there's a lot of things
that ought to be done differently to how debsums/pkg.md5sums work
(secure hash, checking conffiles, stuff in /var, checking added files,
checking additional diversions, preventing
addition/deletion/modification of the md5sums files...).

(Well, better handling of the md5sums files themselves could be useful
for basic integrity checking too -- a disk/fs error that trashes files
in /var/lib/dpkg/info/ can be inconvenient too)

Cheers,
aj

-- 
Anthony Towns 


--
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/87b3a4191003091145p26467cag8d2d4cfb9dc20...@mail.gmail.com

Re: dsniff is dead, long life to dsniff

[Tiago Bortoletto Vaz]

Citando Carlos Galisteo :

On Tue, Mar 9, 2010 at 5:01 PM, Luciano Bello  wrote:


       The question is: should I package this new version as a replacement
of the previous one, even one there is a big reduction in the feature
list? Or, should I create a new package (let's say, python-dsniff) and
RM dsniff?


 As an occasional dsniff user, I'd rather keep the full (old) version
in Debian while the new one is incomplete.

 If the new package is a Python module it'd be nice to have it also in
Debian in order to familiarize ourself with it, but IMHO the original
one should not be removed until the new one is full-featured.


I second that.

It´s not so bad in popcon (1483 installs) and I can´t see any serious  
issue in bts.


If it´s a problem to you maintaing old + new dsniff please ping me.  
I´m interested in keeping this package in Debian. You can also  
consider Forensics team.


Best regards,

--
Tiago Bortoletto Vaz


--
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/20100309170016.9277682i7sljy...@ssl.eumx.net

Re: dsniff is dead, long life to dsniff

[Faidon Liambotis]

Luciano Bello wrote:
>   I'm the dsniff[1] maintainer, which is a pretty dead project[2]. Dug
> Song (the upstream) is putting his efforts in rewrite the project in
> python[3], which is quite limited compared to the previous one.
>   The question is: should I package this new version as a replacement
> of the previous one, even one there is a big reduction in the feature
> list? Or, should I create a new package (let's say, python-dsniff) and
> RM dsniff?
Dug has gave me his permission and blessing to adopt dsniff (as in, the
upstream), keeping the original name.

It has been a while (= 2 years) since I was in that discussion -- I was
 the Debian maintainer back then, had ported dsniff to libnet 1.1 from
1.0 and wanted all these debian/patches to be merged upstream. He
mentioned the Python version back then too FWIW.

I am lacking free time but if anyone else is up to it (Luciano?), I'd
happily collaborate to maintain the original project.

In any case, I think that keeping the same name for the Python version
would be a mistake.

Regards,
Faidon


-- 
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/4b96b17a.3050...@debian.org

Bug#573236: RFP: logfsprogs -- LogFS file system utilities

[Witold Baryluk]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, riku.voi...@iki.fi, 
dan...@lists.debian-maintainers.org


   Package name: logfsprogs
Version: 
Upstream Author: Joern Engel 
URL: http://logfs.org/
License: GPL
Description: LogFS file system utilities

LogFS is a scalable flash filesystem. It is aimed to replace JFFS2 for
most uses, but focuses more on large devices. JFFS2 works well enough on
small devices, it just gets slow (for example mounting can take minutes)
and uses up too much memory on larger ones.

This package contains utilities needed to create (mklogfs) and check
consistency (logfsck) of LogFS file system.

NOTE: You will also need at least version 2.6.34 of the Linux kernel
with proper modules to use this file system.

WARNING: LogFS in its current state it is still very experimental and
should not be used for other than testing purposes.




As of merging of logfs into mainline kernel after more than 2 years of
development, it would be nice to have packaged mkfs.logfs (mklogfs) etc.

ABI, interfaces, and format is still not stablized, but having
this tools will simplify testing for most of users.


I added mtd-utils and btrfs-tools and nilfs2-tools maintainers as CC,
maybe they are interested in packaging this very simple program.

Probably most boring work will be writing man page.
Also compression support need to be documented (chattr +c, chattr -c,
du).


Thanks.





-- 
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/1268177766.21375.23.ca...@sredniczarny

need help of Octave language expert

[Atsuhito Kohda]

Hi all,

I, a maintainer of TeXmacs, try to make TeXmacs as sane
as possible before squeeze release.

I noticed recently that if one starts Octave plugin under 
TeXmacs, it displays an error messages as follows:

-
parse error near line 8 of file 
/usr/share/texmacs/TeXmacs/plugins/octave/octave/.octaverc

  syntax error

>>>gset terminal postscript eps enhanced color;
 ^

parse error near line 8 of file 
/usr/share/texmacs/TeXmacs/plugins/octave/octave/.octaverc

  syntax error

>>>gset terminal postscript eps enhanced color;
^

parse error near line 8 of file 
/usr/share/texmacs/TeXmacs/plugins/octave/octave/.octaverc

  syntax error

>>>gset terminal postscript eps enhanced color;
  ^

parse error near line 8 of file 
/usr/share/texmacs/TeXmacs/plugins/octave/octave/.octaverc

  syntax error

>>>gset terminal postscript eps enhanced color;
   ^

parse error near line 9 of file 
/usr/share/texmacs/TeXmacs/plugins/octave/octave/.octaverc

  syntax error

>>>gset size 0.5,0.5;
 ^

error: near line 9 of file 
`/usr/share/texmacs/TeXmacs/plugins/octave/octave/.octaverc'
error: near line 1 of file `tm-start.oct'
  Dead

Octave]
-

I don't know if Octave plugin starts or fails to start but anyway
this is very annoying.  
I suspect that TeXmacs plugin for Octave is obsolete but, as
I don't know Octave language at all, so I request a help of Octave
language expert.

ii  octave3.0   1:3.0.5-7+b1   GNU Octave language for numerical computatio
ii  texmacs 1:1.0.7.3-3WYSIWYG mathematical text editor using TeX f

I attach problematic files mentioned in the above messsages.
If someone finds any fix, I greatly appreciate.
Thanks in advance.

Best regards,   2010-3-10(Wed)

-- 
 Debian Developer - much more I18N of Debian
 Atsuhito Kohda 
 Department of Math., Univ. of Tokushima


octave-files.tar.gz
Description: Binary data

Re: Bug#572374: please consider Section: Education

[Charles Plessy]

Le Tue, Mar 09, 2010 at 08:36:24AM +0100, Andreas Tille a écrit :
> 
> While I agree in principle with this attempt there might be a lot of
> packages which fit into Science *and* Education section.  The sections
> approach in Debian is weak in the way that a package can only be put in
> one section.  The alternatives are DebTags and the Blends tasks.  If you
> compare the tasks of Debian Science[1] and Debian Edu[2] in the
> "typical" sciences Astronomy, Chemistry, Electronics, Mathematics and
> Physics you will realise the problem.

Hi all,

I agree with Andreas here: we already have other ways to classify software, in
particular with the Debtags, and to group packages, in particular with the
Blends tasks, so fragmenting the sections will only introduce doubts and
controversy about multi-purpose software.

How about renaming the Science section “Science and Education” (or “Education
and Scicence”, it does not matter to me). The content of the ‘Section’ field in
the Debian control files could stay ‘science’, since if I understand the
problem, what matters here is the processed information that our users see on
our website.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20100310044007.ga9...@kunpuu.plessy.org

Re: Bug#540215: Introduce dh_checksums

[Peter Samuelson]

[Harald Braumann]
> See, you don't need a server. You just ship a signature over the hash
> files. Easy as that.

And that signature - if you don't have a server - you probably want to
store it in the .deb, right?  So you are going to be editing the .deb
after it is built.  At which time, you could just as well compute your
SHA16384 hashes, sign those, and store them.  That way you can even use
an attached (as opposed to detached) gpg signature, without confusing
downstream tools.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20100310051154.gs18...@p12n.org

Re: need help of Octave language expert

[Thomas Weber]

Hi, 

I'm cc'ing debian-devel, so people see that there is an answer. If
whoever wants to continue the discussion, please strongly consider
dropping debian-devel -- the list is noisy enough.

On Wed, Mar 10, 2010 at 12:06:06PM +0900, Atsuhito Kohda wrote:
> Hi all,
> 
> I, a maintainer of TeXmacs, try to make TeXmacs as sane
> as possible before squeeze release.
> 
> I noticed recently that if one starts Octave plugin under 
> TeXmacs, it displays an error messages as follows:
> 
> -
> parse error near line 8 of file 
> /usr/share/texmacs/TeXmacs/plugins/octave/octave/.octaverc
> 
>   syntax error
> 
> >>>gset terminal postscript eps enhanced color;

Directly accessing gnuplot (which is what 'gset' did) is deprecated in
octave3.0 and even more in the 3.2 series. Spending time on this issue
is probably wasted, unless TeXmacs' upstream is willing to adapt the
necessary changes.

Following 
http://old.nabble.com/octave-plugin-maintainership-td26618436.html
it seems Mansour Moufid wanted to take over maintenance of the plugin. I
suggest getting in contact with him.


> I attach problematic files mentioned in the above messsages.
> If someone finds any fix, I greatly appreciate.

In essence, the plot commands in the file need a rewrite. Sorry, but my
problem is just the other way round: I have zero knowledge about
TeXmacs.

Thomas


-- 
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/20100310073433.ga11...@atlan