Bug#474602: ITP: nikto -- web server security scanner

[Javier Fernández-Sanguino Peña]

On Sun, Apr 06, 2008 at 07:29:09PM +0200, Vincent Bernat wrote:
> * Package name: nikto

Nikto was already packaged for Debian (etch provided version 1.35). It was
removed from Debian (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434392).

Please, include the debian information (including changelog history) from
the old Debian packages and use that as a starting point. I'm not sure how 
many of the patches introduced in the Debian package are current, but it
would be best if you evolved from that instead of making new packages from
scratch.

Regards

Javier


signature.asc
Description: Digital signature

Bug#353917: ITP: lanmap -- lanmap sits quietly on a network and builds a picture of what it sees.

[Javier Fernández-Sanguino Peña]

On Tue, Feb 21, 2006 at 01:22:57PM -0800, Sebastien Delafond wrote:
> * Package name: lanmap
>   Version : 0.1
>   Upstream Author : Ryan Flynn <[EMAIL PROTECTED]>
> * URL : http://parseerror.com/lanmap/
> * License : GPL
>   Description : lanmap sits quietly on a network and builds a picture of 
> what it sees.
> 
> lanmap simply listens to all available traffic on the interface of your
> choice, figures out who's talking to who, and how much and using which
> protocols. From each packet we can usually glean some little hint at
(...)

This software looks interesting, but very similar to PADS
(http://passive.sourceforge.net/) which is already packaged for Debian.
Besides being able to use Graphviz to generate network "maps" which
differences does it have with Pads?

Regards

Javier


signature.asc
Description: Digital signature

Bug#353917: ITP: lanmap -- lanmap sits quietly on a network and builds a picture of what it sees.

[Javier Fernández-Sanguino Peña]

On Tue, Feb 21, 2006 at 04:11:40PM -0800, Sebastien Delafond wrote:
> 
> Should the similarities between PADS and lanmap prevent the latter
> from being packaged for Debian ? I understand they both rely on

Of course not!

> passive network monitoring to produce info, but I still don't see that
> as an obstacle to packaging lanmap in Debian.

Maybe commenting on what features you feel "make a difference" on this
package vs. others will help users decide which one to install.

Regards

Javier


signature.asc
Description: Digital signature

Bug#360357: ITP: diff1 -- compares file's actual state with file's desired state

[Javier Fernández-Sanguino Peña]

On Sat, Apr 01, 2006 at 09:00:45AM -0500, Jay Berkenbilt wrote:
> At this point, diff1 is still under development and depends upon the
> utm (Universal Truth Machine) and dwim (Do What I Mean) libraries.
> The eventual goal is that diff1 should be "self-hosting" -- the final,
> bug-free version of diff1 will be generated by running diff1 on its
> own sources, at which point it will be finished and will be able to
> determine the correct answers to all questions that can be expressed
> using written language.

Let me guess, will it always answer '42' to any and all questions?

Regards

Javier


signature.asc
Description: Digital signature

Bug#361253: ITP: zenoss -- Zenoss is a powerful, integrated, easy-to-use IT infrastructure monitoring software product.

[Javier Fernández-Sanguino Peña]

On Fri, Apr 07, 2006 at 03:01:28PM +0200, Wolfgang Lonien wrote:
> * Package name: zenoss
>   Version : x.y.z

Version?

>   Description : Zenoss is a powerful, integrated, easy-to-use IT 
> infrastructure monitoring software product.

That's too long for a short a description 

> Zenoss provides a compelling alternative to:
> * low-end commerical monitoring tools that provide limited 
(...)

This description does not describe what Zenoss does, how it compares to other
OSS monitoring or management systems (like Nagios, Cheops, Cacti, Mrtg, 
Rddtool...)
it also should *not* include names of propietary products since that does not
help people that do not know them to determine what Zenoss actually does.

Please state facts and features, that description is pure maketing b**t.
Please, re-read the Developer's Reference, "6.2.1 General guidelines for
package descriptions" available at
http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-desc-basics

Regards

Javier


signature.asc
Description: Digital signature

Bug#289168: will this package ever be included in debian?

[Javier Fernández-Sanguino Peña]

On Tue, Nov 06, 2007 at 08:11:40PM -0600, Lukasz Szybalski wrote:
> Hello,
> I was wondering what is the current holdup for this package to make it
> into repository?

Time. It was rejected because the packages I provided where not good enough:

"rejected - you need to fix your debian/copyright, see
http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
for some details.

You miss to mention a lot of different licenses with a lot of different
(C) holders."

If someone wants to do a (C) audit of the sources I can provide a copy of my
packages somewhere. I just don't have the time to do it currently.

Regards

Javier


signature.asc
Description: Digital signature

Bug#592137: RFH: bastille - Security hardening tool

[Javier Fernández-Sanguino Peña]

Package: wnpp
Severity: normal

I would appreciate help with the bastille package, a security tool to
lockdown systems. 

The current version in Debian (3.0.9) was heavily modified to work in Debian
but, alas, patches were sent but not incorporated upstream. The latest
upstream version (3.2.1) was released in September 2008. Upstream is no
longer active with this tool and no updates are forthcoming. 

In any case, the Bastille tool could be rather useful to Debian users if it
could allow them to easily implement most of the steps required to secure a
Debian system (some of which are described in the Securing Debian Manual
[1]).

Steps that I would need help with:

 - Move over Bastille in Debian to an Alioth Project and push to SVN or
   GIT all the different releases
 - Separate Debian-specific patches from the original sources (turn to quilt
   or other patch-handling tool)
 - Update the Debian API for 3.2.1
 - Test and get out a  3.2.1 release for Debian

Regards

Javier


[1] http://www.debian.org/doc/manuals/securing-debian-howto/index.en.html





signature.asc
Description: Digital signature

Bug#597202: ITP: kstars-data-extra-tycho2 -- Contains the Tycho2 star catalog for centralized install, avoiding per-user install

[Javier Fernández-Sanguino Peña]

Hi,

First of all, please first note there is an informal policy for Stars data
catalogues which is available in the 'stardata-common' package (more info at
http://alioth.debian.org/projects/stardata-common/). We already provide some
star data catalogues (Gliese and Yale which are both non-free) in Debian
and we should strive to follow the same rules for any star data catalogues
we provide.

> Actually kstars offer each user to download some data, from the net, which
> causes bandwith and disk waste (See #596007). I will package one of those
> datafiles (one of the catalogs) to avoid that, and I want to package the
> remaining afterwards.

If you are packaging datfile it would be best if they follow the policy above
so that other astronomy packages (stellarium, stardata, etc.) can use them.
This means using the original (unmodified) files and providing scripts/tools
(which probably the Kstars team has developed) to convert them into files
usable for other software.

> * Package name: kstars-data-extra-tycho2
>   Version : 1.1r1
>   Upstream Author : Akarsh Simha, Jason Harris 

The 'upstream authors' of the Tychos2 catalog are not some KDE developers
(with all my respect to their work). Please see
http://www.astro.ku.dk/~erik/Tycho-2/ From
http://www.astro.ku.dk/~erik/Tycho-2/Tenyears.eml the autors are E. Høg,
C. Fabricius, V.V. Makarov, S. Urban, T. Corbin, G. Wycoff, U. Bastian,
P. Schwekendiek, and A. Wicenec.

> * URL : 
> http://edu.kde.org/kstars/downloads/tycho2_mag_12.5-1.1.tar.bz2

The URL for the upstream catalog is not correct. This is the URL for the
files distributed by KDE which are maybe *not* the original files.

> * License : GPL

This license is *not* the license the Tycho2 catalog was distributed with
10 years ago (8th february 2000). It might be worth clarifying with
Erik Høg, original author of the catalog from the Niels Bohr Institute
under which license this catalog can be distribued.

Please note that other catalogues distributed by international
organisations (ESA, NASA) have had a 'please do not modify these files'
strings attached and have thus fallen into non-free (see gliese and
yale catalogues).

>   Programming Lang: N/A
>   Description : Contains the Tycho2 star catalog for centralized install, 
> avoiding per-user install

If the package provides the Tycho2 star data catalogue it should provide the
*original* catalogue as available in
http://tdc-www.harvard.edu/catalogs/tycho2.html and not a "pre-cooked" file
for kstars. If it provides a pre-cooked file for kstars then it should note
it.

As for the license, I do not agree with the license you set up for this
package. If you review http://cdsarc.u-strasbg.fr/cgi-bin/myqcat3?I/259/, the
Tychos star data catalogue files are certainly *not* GPL. There is no mention
to the license the catalog can be used with in the README file, and certainly
there is no mention to the GPL. As such, it can only be considered
'non-free'.

Actually, I believe that the fact that the catalog is not provided *within*
the kstars program is certainly because it is not considered free.

Please review the licensing status of the original data files before you make
an upload of this package to Debian.

If you are interested in astronomy packages, I encourage you to subscribe to
the stardata-common-devel mailing list to seek assistance on how to
(properly) package star data catalogues in Debian.

Regards

Javier



-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100919120303.gb9...@javifsp.no-ip.org

Bug#597202: ITP: kstars-data-extra-tycho2 -- Contains the Tycho2 star catalog for centralized install, avoiding per-user install

[Javier Fernández-Sanguino Peña]

On Sun, Sep 19, 2010 at 05:24:38PM +0100, Noel David Torres Taño wrote:
> > > * License : GPL
> > 
> > This license is *not* the license the Tycho2 catalog was distributed
> > with 10 years ago (8th february 2000). It might be worth clarifying with
> > Erik Høg, original author of the catalog from the Niels Bohr Institute
> > under which license this catalog can be distribued.
> > 
> > Please note that other catalogues distributed by international
> > organisations (ESA, NASA) have had a 'please do not modify these files'
> > strings attached and have thus fallen into non-free (see gliese and
> > yale catalogues).
> 
> That is the license of the file I'm distributing. Should I contact Simha and 
> Harris to see if THEY are violating the Tycho-2 catalog license?

Please confirm with them that this *derived* data from the Tycho-2 can be
indeed GPL-licensed. I would be very surprised if this is the case (I've had
contact with some producers of star data catalogues in the past) but if it is
fine.

We packaged the Gliese and Yale packages as they are right now (in non-free
and including the original sources with data files for starplot generated on
install) as the upstream authors would not allow for modification of the star
data catalogs.

Throughout the years maintainers (both Debian and upstream's) have learnt of
this "the hard way", i.e.  bugs in celestia: #174456, stellarium #198495,
kstars #198499, xephem 225002 and stars: #246047, gstar #246048, openuniverse
#246049.

Some upstream developers (kstars') were very helpful in the past. When we
took this issue up with them, the kstars team (Jason Harris mainly) digged up
contacts with the catalog providers. 

This is what someone from CDS replied (when asked about Hipparcos and SAO
catalogs):

: Catalogues available at CDS contain scientific data distributed
: for free, for a scientific usage. Only the expenses related to
: copying and mailing are charged if relevant.
: Companies including such data in their commercial products cannot
: charge their clients for the data. Furthermore, users must be informed
: of the origin of the data: this means an explicit reference to the service
: provided by the CDS and also to the original author(s) of each catalogue.
:

So this initially made the catalogs used by kstars non-free, they then
contacted people at ESA which confirmed that Hipparcos was in the
public-domain:

:  Hello Jason,
:
:  The Hipparcos data is in the public domain and may be used
:  by anyone. We do request however that use of the catalogue data
:   is acknowledged. Something similar to "This application
:  makes use of the  Hipparcos and Tycho catalogues (ESA, 1997)"
:  could be appropriate, and a link to the ESA Hipparcos web pages
:  (http://sci.esa.int/hipparcos) would also be appreciated.
:
:  Can I enquire what you would like to use the catalogue for?
:
:  Regards,
:  Karen O'Flaherty

As a consequence kstars switch to the Hypparcos catalog (and many other
astronomy packages too).

Since the main author of the Tycho2 catalog is Erik Høg I suggest asking
the kstars developed if they have contacted him regarding the catalog and, if
not, get clarification from him


> > Actually, I believe that the fact that the catalog is not provided *within*
> > the kstars program is certainly because it is not considered free.
> 
> I believe instead that the fact that the catalog is not provided *within* the 
(...)
> own set of predefined stars up to the visual magnitude. Datafile authors
> (which are, by the way, two of the same authors of the program itself) say
> the datafile is GPL, so I can not think they decided not to include it
> because of it being not free.

Please, take this up with upstream for clarification because in the past
other upstreams have made the same assumptions which turned out not to be
valid with other catalogs (i.e. yale). It would be best to seek clarification
from the author.  I don't see GPL anywhere at
http://www.astro.ku.dk/~erik/Tycho-2/, in fact, I don't see any reference to
licenses at all so I'm quite sure the original author do not stamped a GPL
license to the data.

Since upstream developers (kstars) where very open to discussion and where
really helpful when we brought to them this issue 7 years ago, they probably
have researched this issue, but a statement from the original author of the
catalog (to be used in debian/copyright) would be good to have.

Regards

Javier



signature.asc
Description: Digital signature

Bug#601626: ITP: sshuttle - Transparent proxy server for VPN over SSH

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A; reported 2010-10-27
Severity: wishlist

Package name : sshuttle
Version : 0.42
Upstream Author : Avery Pennarun 
URL : http://github.com/apenwarr/sshuttle
License :  LGPL v2
Description: Transparent proxy server for VPN over SSH
 Sshuttle makes it possible to access remote networks using
 SSH. It creates a transparent proxy server that will forward
 all the traffic through an SSH tunnel to a remote copy
 of sshuttle.
 .
 It does not require installation on the remote server, which
 just needs to have python installed.

--

Upon request from the upstream maintainer (which is also upstream
for netselect, already packaged in Debian) I have prepared some
packages for shuttle for Debian.

A pre-release of the package, for those interested in this software,  is
available at http://people.debian.org/~jfs/sshuttle/

If there are testers out there I would appreciate reports on the package so
that the first Debian release is up to our standards.

Regards

Javier


signature.asc
Description: Digital signature

Bug#148988: ITP: Nat -- Netbios Auditing Tool

[Javier Fernández-Sanguino Peña]

On Tue, Jun 04, 2002 at 01:47:13PM +0200, Erich Schubert wrote:
> >   Package name: Nat
> 
> There had been some smb-nat package before; i don't know why it was
> removed, you might want to talk to the samba maintainers.

Ok. Will do, thanks.

Javi


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

Bug#82613: Crack license, is it free?

[Javier Fernández-Sanguino Peña]

(please CC: since I'm not in the list)

I understand that crack's [1] license (adjointed) is free, however, I'm
surprised its not in Debian yet (whileas john is). I just wanted to check
before packaging it (there's an ITP #82613 but it's almost 2 years ago),
since it sounds DFSG-compatible to me.

Regards

Javi

A search in debian-legal regarding 'crack' brings nothing useful except
the informaion that both  Wichert [2] and Knghtbrds [3] seem to have a
crack pipe somewhere :)

[1] http://www.users.dircon.co.uk/~crypto/download/c50-faq.html
[2] http://lists.debian.org/debian-legal/2000/debian-legal-27/msg00059.html
[3]http://lists.debian.org/debian-legal/2000/debian-legal-200010/msg00063.html

-- 
**

Throughout the entire history of the Crack software, the author has
been employed (apart from occasional periods of unemployment) by a
selection of academic institutions and companies, none of whom have
ever dedicated any resources to the development of the software, nor
have endorsed the development of the software in any other way.

None of these institutions and companies bear any responsibility
whatsoever for the software, including (but not restricted to)
responsibility for its existence, structure, content, function or use
by any person anywhere.

**

The author would like to take this opportunity to thank those freeware
authors who have made indirect but positive contributions to the
development of Crack, notably:

* Michael Glad (UFC) and Eric Young (libdes/SSLeay) for developments
in the field of high-speed cryptographic implementation which have
provided core functionality for Crack since 1991,

* The Free Software Foundation for EMACS, GCC, and a variety of other
essential software development tools,

* Larry Wall for Perl (of which I cannot speak highly enough), and...

* Linus Torvalds and all other contributors to the Linux project,
which has provided the operating system upon which Crack has been
developed for the last few years.

The author would also like to thank Paul Leyland for the suggestion of
several ideas key to the new release of the software, notably DAWG
dictionary compression and dictionary handling techniques.

**

(*
This document is freely plagiarised from the 'Artistic Licence',
distributed as part of the Perl v4.0 kit by Larry Wall, which is
available from most major archive sites
*)

This documents purpose is to state the conditions under which this
Package (See definition below) viz: The "Crack" Password Cracker, which
is copyright Alec David Edward Muffett, may be copied, such that the
Copyright Holder maintains some semblance of artistic control over the
development of the package, while giving the users of the package the
right to use and distribute the Package in a more-or-less customary
fashion, plus the right to make reasonable modifications.

**

Definitions:

"Package" refers to the collection of files distributed by the Copyright
Holder, and derivatives of that collection of files created through
textual modification, or segments thereof.

"Standard Version" refers to such a Package if it has not been modified,
or has been modified in accordance with the wishes of the Copyright
Holder.

"Copyright Holder" is whoever is named in the copyright or copyrights
for the package.

"You" is you, if you're thinking about copying or distributing this
Package.

"Reasonable copying fee" is whatever you can justify on the basis of
media cost, duplication charges, time of people involved, and so on.
(You will not be required to justify it to the Copyright Holder, but
only to the computing community at large as a market that must bear the
fee.)

"Freely Available" means that no fee is charged for the item itself,
though there may be fees involved in handling the item.  It also means
that recipients of the item may redistribute it under the same
conditions they received it.


1.  You may make and give away verbatim copies of the source form of the
Standard Version of this Package without restriction, provided that you
duplicate all of the original copyright notices and associated
disclaimers.

2.  You may apply bug fixes, portability fixes and other modifications
derived from the Public Domain or from the Copyright Holder.  A Package
modified in such a way shall still be considered the Standard Version.

3.  You may otherwise modify your copy of this Package in any way,
provided that you insert a prominent notice in each changed file stating
how and when AND WHY you changed that file, and provided that you do at
least ONE of the following:

a) place your modifications in the Public Domain or otherwise make them
Freely Available, such as by posting said modifications to Usenet or an
equivalent medium, or placing the modifications

Bug#216878: RFA: gliese

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: unavailable; reported 2003-10-21
Severity: normal

I no longer have time to maintain gliese (and other astronomy related
packages). Prospective maintainers should contact me since I would like to
point out some issues in astronomy-related software in Debian that would
need to be coordinated too. Also, since starplot Suggests
'gliese', they should be taken together.

The package is in sync with upstream and lintian clean.

Regards

Javi

Bug#216877: RFA: yale

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: unavailable; reported 2003-10-21
Severity: normal

I no longer have time to maintain yale (and other astronomy related
packages). Prospective maintainers should contact me since I would like to
point out some issues in astronomy-related software in Debian that would
need to be coordinated too. Also, since starplot Suggests 
'yale', they should be taken together.

The package is in sync with upstream and lintian clean.

Regards

Javi



pgpHqsp74wVcG.pgp
Description: PGP signature

Bug#216879: O: roleplaying

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: unavailable; reported 2003-10-21
Severity: normal

I no longer have time to maintain roleplaying any more, and I no longer use 
it myself, so it would be better of in other's hands.

The package has only one outstanding bug asking to update to upstream, but 
the new upsteam release is non-free. Maintainers interested should need to 
talk upstream, and decide to either remove the package from Debian or keep 
the old (and unsupported) version (and clean all the lintian problems).

New upstream available at 
http://www.deepsoft.com/cgi-bin/deepwoods.cgi/RolePlayingDB

Regards

Javi

Bug#216876: RFA: starplot

[Javier Fernández-Sanguino Peña]

Subject: RFA: starplot
Package: wnpp
Version: unavailable; reported 2003-10-21
Severity: normal

I no longer have time to maintain starplot (and other astronomy related
packages). Prospective maintainers should contact me since I would like to
point out some issues in astronomy-related software in Debian that would
need to be coordinated too. Also, since starplot Suggests 'gliese' and 
'yale', they should be taken together.

The package is in sync with upstream (last release is 0.94.1), almost
lintian clean and needs to be updated to latest Debian policy. 

Regards

Javi


pgptEKna41S12.pgp
Description: PGP signature

Bug#216874: RFA: spacechart

[Javier Fernández-Sanguino Peña]

Subject: RFA: spacechart
Package: wnpp
Version: unavailable; reported 2003-10-21
Severity: normal

I no longer have time to maintain spacechart (and other astronomy related
packages). Propsective maintainers should contact me since I would like to
point out some issues in astronomy-related software in Debian that would
need to be coordinated too.

The package is in sync with upsteam, almost lintian clean and needs to be
update to latest Debian policy.

Regards

Javi

Bug#216883: RFA: lmbench - Utilities to benchmark UNIX systems

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: unavailable, reported 2003-10-21
Priority: normal

I can no longer dedicate time to lmbench, so I'm orphaning this package.

Upstream version (http://www.bitmover.com/lmbench) is currently 2.0.3 and
the Debian package would need to be updated (currently 2.0) from
http://sourceforge.net/projects/lmbench/. Announcement is at
http://www.bitmover.com/pipermail/lmbench-users/2002-October/43.html
and at sourceforge. Prospective maintainers need to retrieve the new
release and update the package.

However upstream is not very active, and neither is the mailing list 
(http://www.bitmover.com/pipermail/lmbench-users/).

Also notice that lmbench would need to be built in other arquitectures in 
order to make it available in testing. I don't really don't know why its 
not autobuilt.

Regards

Javi


pgpn2cYV6kAlF.pgp
Description: PGP signature

Bug#222687: ITP: kernel-patch-adamantix : patches included in the Adamantix distribution

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A reported 2003-11-29
Priority: wishlist

In order to get a broader testing and to resolve some of the recent 
discussions at -devel and -security, here it goes:

 dpkg --info kernel-patch-adamantix_1_all.deb
 new debian package, version 2.0.
 size 564952 bytes: control archive= 890 bytes.
 760 bytes,19 lines  control
 600 bytes, 7 lines  md5sums
 Package: kernel-patch-adamantix
 Version: 1
 Section: devel
 Priority: extra
 Architecture: all
 Depends: bash (>= 2.0), patch, grep-dctrl
 Suggests: kernel-source-2.4.21, kernel-package
 Installed-Size: 628
 Maintainer: Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>
 Description: Kernel patches introduced in Adamantix
  This patch provides the kernel patches introduced in the Adamantix
  default kernel which includes: RSBAC support, PaX, MPEE support,
  Random PID, Random IP port, and Linux Virtual Server support.
  .
  This patches allow the introduction of Mandatory Access Control
  (MAC) through RSBAC and buffer overflow protection through PaX and
  thus competes/conflicts with SElinux and the exec-shield respectively.
  .
  Homepage: http://www.adamantix.org


Version: this will be a native Debian package, it is currently based on 
 Adamantix's 2.4.21-12 kernel source package.
License: GPLv2
URL: http://www.adamantix.org
Upstream Author: Peter Busser <[EMAIL PROTECTED]> (for the patch 
collection) and original sources (including the PaX Team) for the patches 
themselves.

Regards

Javi


signature.asc
Description: Digital signature

Bug#222688: ITP: paxtest - PaX regression suite

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A reported 2003-11-29
Priority: wishlist


Upstream developer: Peter Busser <[EMAIL PROTECTED]>
License: GPL

$ dpkg --info paxtest_0.9.5-2_i386.deb 
 new debian package, version 2.0.
 size 23496 bytes: control archive= 1779 bytes.
 981 bytes,23 lines  control
2415 bytes,40 lines  md5sums
 Package: paxtest
 Version: 0.9.5-2
 Section: devel
 Priority: optional
 Architecture: i386
 Depends: libc6 (>= 2.3.2.ds1-4)
 Installed-Size: 212
 Maintainer: Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>
 Description: Test suite for the PaX kernel patch
  PaX is a Linux kernel patch which adds much stricter control on how memory
  is being used by applications. A normal Linux kernel leaves the control to the
  application and does not implement any enforcement. Especially buffer overflow
  attacks benefit from the absense of kernel enforced memory control. PaX tries
  to do its best to enforce this control of memory used by applications, thereby
  making it harder to succesfully exploit buffer overflows.
  .
  Furthermore, it adds several randomisations, which also make it harder for
  buffer overflows to succeed.
  .
  The test programs test all this functionality, but not all PaX functionality
  is covered.
  .
  For more information about PaX, see http://pageexec.virtualave.net/.

Notice this will be the original paxtest package developed by Peter with
some (slight) changes.

Regards


Javier


signature.asc
Description: Digital signature

Bug#222481: ITP: paxtest - PaX regression suite

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A reported 2003-11-29
Priority: wishlist


Upstream developer: Peter Busser <[EMAIL PROTECTED]>
License: GPL

$ dpkg --info paxtest_0.9.5-2_i386.deb 
 new debian package, version 2.0.
 size 23496 bytes: control archive= 1779 bytes.
 981 bytes,23 lines  control
2415 bytes,40 lines  md5sums
 Package: paxtest
 Version: 0.9.5-2
 Section: devel
 Priority: optional
 Architecture: i386
 Depends: libc6 (>= 2.3.2.ds1-4)
 Installed-Size: 212
 Maintainer: Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>
 Description: Test suite for the PaX kernel patch
  PaX is a Linux kernel patch which adds much stricter control on how memory
  is being used by applications. A normal Linux kernel leaves the control to the
  application and does not implement any enforcement. Especially buffer overflow
  attacks benefit from the absense of kernel enforced memory control. PaX tries
  to do its best to enforce this control of memory used by applications, thereby
  making it harder to succesfully exploit buffer overflows.
  .
  Furthermore, it adds several randomisations, which also make it harder for
  buffer overflows to succeed.
  .
  The test programs test all this functionality, but not all PaX functionality
  is covered.
  .
  For more information about PaX, see http://pageexec.virtualave.net/.

Notice this will be the original paxtest package developed by Peter with
some (slight) changes.

Regards

Javier Fernandez-Sanguino

Bug#222479: ITP: kernel-patch-adamantix

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A reported 2003-11-29
Priority: wishlist

In order to get a broader testing and to resolve some of the recent 
discussions at -devel and -security, here it goes:

 dpkg --info kernel-patch-adamantix_1_all.deb
 new debian package, version 2.0.
 size 564952 bytes: control archive= 890 bytes.
 760 bytes,19 lines  control
 600 bytes, 7 lines  md5sums
 Package: kernel-patch-adamantix
 Version: 1
 Section: devel
 Priority: extra
 Architecture: all
 Depends: bash (>= 2.0), patch, grep-dctrl
 Suggests: kernel-source-2.4.21, kernel-package
 Installed-Size: 628
 Maintainer: Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>
 Description: Kernel patches introduced in Adamantix
  This patch provides the kernel patches introduced in the Adamantix
  default kernel which includes: RSBAC support, PaX, MPEE support,
  Random PID, Random IP port, and Linux Virtual Server support.
  .
  This patches allow the introduction of Mandatory Access Control
  (MAC) through RSBAC and buffer overflow protection through PaX and
  thus competes/conflicts with SElinux and the exec-shield respectively.
  .
  Homepage: http://www.adamantix.org


Version: this will be a native Debian package, it is currently based on 
 Adamantix's 2.4.21-12 kernel source package.
License: GPLv2
URL: http://www.adamantix.org
Upstream Author: Peter Busser <[EMAIL PROTECTED]> (for the patch 
collection) and original sources (including the PaX Team) for the patches 
themselves.

Regards

Javi

Bug#225456: ITP: skdetect -- program to detect the suckit rootkit

[Javier Fernández-Sanguino Peña]

On Tue, Dec 30, 2003 at 12:39:04AM +0100, Benoit Mortier wrote:
> * Package name: skdetect
(...)
>   Description : program to detect the suckit rootkit
> 
>  skdetect scans the current running system for the suckit rootkit.
>  The source is based on sk-1.3b.
>  .
>  There is two executables skdetect and skdetect.static who is
>  staticaly compiled

How is this better than chkrootkit? Shouldn't it be better integrated
there?  Having small programs with a very limited functionality when there
is one that people know of that _should_ cover its corner case is not good
for our users IMHO.

Regards

Javi


signature.asc
Description: Digital signature

Bug#225456: ITP: skdetect -- program to detect the suckit rootkit

[Javier Fernández-Sanguino Peña]

On Tue, Dec 30, 2003 at 02:35:41PM +0100, Benoit Mortier wrote:
Content-Description: signed data
> 
> maybe the statically linked package could be usefull alone in case of an 
> incident ?

I don't know (as I have never used this skdetect thing) but if it's useful
the statically linked version could be included in the chkrootkit package
too. In any case, if you have a kernel-level rootkit it is not really
relevant if you are useing a static-compiled or dynamicly-linked program, 
it can fool both. The only sure way is to analyse the system after powering 
it  off from trusted media.

Regards

Javi


signature.asc
Description: Digital signature

Bug#93364: ITP easyfw

[Javier Fernández-Sanguino Peña]

Package: wnpp
Priority: wishlist

This is an ITP for easyfw. Currenlty (unfishinished) package is
available at: http://www.dat.etsit.upm.es/~jfs/debian/DO/easyfw/easyfw-2.2/
Package: easyfw
Architecture: all
Depends: netbase, wish
Description: Graphical interface to ipchains/ipfwadm
 Easy firewall is graphical interface to ipchains or ipfwadm, allowing to
 generate a ipchains/ipfwadm command script. The script can be used to
 execute the firewall rules on startup, or can be applied instanty.

Bug#93365: ITP openuniverse

[Javier Fernández-Sanguino Peña]

Package: wnpp
Priority: wishlist

I intentd to package 'openuniverse' a Solar System simulator that can
be retrieved from http://www.openuniverse.org
Current, (unifnished) package is available at:
http://www.dat.etsit.upm.es/~jfs/debian/DO/openuniverse/

Bug#93367: ITP oncelinux

[Javier Fernández-Sanguino Peña]

Package: wnpp
Priority: wishlist

I intentd to package 'OnceLinux' a set of drivers and programs for
blind persons available at ftp.once.es/pub/

Currenlty, development packages for this and other blind tools can
be retrieved from the blinux proyect or from:
http://www.dat.etsit.upm.es/~jfs/debian/DO/blind/

Javi

Bug#93368: ITP sara

[Javier Fernández-Sanguino Peña]

Package: wnpp
Priority: wishlist

I intend to package sara, availabe from 
http://home.arc.com/sara/index.html
Development (unfinished) packages are available at
http://www.dat.etsit.upm.es/~jfs/debian/DO/sara/

Package: sara
Architecture: any
Depends: perl5, www-browser, ${shlibs:Depends}
Suggests: nis, nfs-common
Description: Security Auditor's Research Assistant
 This powerful is an evolution of satan which includes many nice
 new features like report generation, new vulnerabilities tested,
 use of nmap features..
 .
 In its simplest mode, it gathers as much
 information about remote hosts and networks as possible by
 examining such network services as finger, NFS, NIS, ftp and tftp,
 rexd, statd, and other services. 
 .
 It is based upon SATAN but is being developed under an 
 open source community effort.
-- 

Bug#89453: ITP for vrrp

[Javier Fernández-Sanguino Peña]

When do you intend to submit the package (the ITP is over 200 days old). If you
find yourself not able to package it I will gladly do it for you :)

Javi

Bug#329941: ITP: portreserve - Port reservation program

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A; reported 2005-09-24
Severity: wishlist

Package name : portreserve
Version : 0.0.0
Upstream Author : Tim Waugh 
URL : http://cyberelk.net/tim/portreserve/
License : GPL
Description :  The portreserve program aims to help services with well-known
ports that lie in the bindresvport() range (currently 600-1023).
It prevents programs requesting a port to the libc from occupying
a real service's port by occupying it itself, until the real service
tells it to release the port (generally in its init script).

Preliminary packages are available at
http://people.debian.org/~jfs/portreserve/

The accompanying README.Debian file is attached

Regards

Javier
portreserve for Debian
--

This package is provided to solve an issue that affects some servers and 
goes like this:

- an RPC server (ypbind, rpc.mountd...) runs on boot and requests a dynamic
  port < 1024 using glibc's bindresvport().
- The libc provides the RPC server with a service in the 600-1023 with the
  following formula 'port = (PID % 424) + 600)', unfortunately, this
  port is the same port of a well known service (cups, laps,
  kadmin, rsync, or SSL-enabled IMAP, IRC and POP3 servers) which has not
  yet started.
- the well-known service tries to start later in the boot sequence and
  fails because the port is assigned


If you look at /etc/services you will see that the services affected
with this issue are typically:

  631 IPP == CUPS
  636 LDAPS
  749 Kerberos V kadmin
  783 SpamAssasin
  873 rsyncd
  992-995 SSL-enabled telnet and ftp, IMAP, IRC, and POP3

It has been suggest a number of times to add these ports to a blacklist
in libc but the glibc maintainers are against this as the affected services
might change with time (Note: sometimes this has been requested in portmap, 
which is wrong since portmap does not assign ports, just registers them after 
being assigned).

Typically local admins would fix this issue by changing the boot order
of services so that the server with the static well-known port was
started first, but sometimes this is not an option (i.e. mail servers
that rely on information maps from NIS). 

Another option for local admins has been to assign static ports 
to the RPC services _if_ the service allows for this 
(like using '-p' with ypserv or ypbind). This also helps in setting
up packet filters for RC services.

What can I do fix this issue?
-
(Written for admins, but maintainers can adapt this easily to their
packages too)

If you are running some of the servers above and are affected by this issue 
you need to 

a) Create a /etc/portreserve/$server file with a single line, the name of
   the service port as found in /etc/services or a service number

b) Modify the /etc/init.d/$server file and add this before the service
   is started:

   [ -x "`which portrelease`" ] && portrelease $server

Notice that some package maintainers might gradually add this by default so
you might find that has already been done for you. If it hasn't you
might want to submit a bug to the Debian package quoting the above and
asking the maintainer to 'Recommend'  portreserve. That way you will
not have to maintain these local changes yourself.

Possible issues:


If an RPC service is already running and you install a new package that
provides a daemon that requires the same port the installation will fail
_even_ if the package uses portreserve and portreserve is installed.

There is no way around this, since it would not make sense to have portrserve 
pre-configured for all possible services that require static ports if an admin 
is never going to install them and it's more manageable to have packages
provide the services than having a central blacklist.

In any case, admins that want to use portreserve as a blacklist regardless
of the service being installed can do that through /etc/portrelease

Further references:
--

Debian BTS:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=261484 [portmap]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306465 [nis]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257876 [nis]

Red Hat's Bugzilla:
https://bugzilla.redhat.com/103401
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154800

Debian mailing lists:
http://lists.debian.org/debian-devel/2004/10/threads.html#00292
http://lists.debian.org/debian-devel/2005/09/thrd3.html#01062

 -- Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>, Sat, 24 Sep 2005 
16:07:56 +0200


signature.asc
Description: Digital signature

Bug#93208: wnpp: RFP: peep, the "Network Auralizer"

[Javier Fernández-Sanguino Peña]

On Sun, Sep 25, 2005 at 04:12:30PM -0500, Drew Scott Daniels wrote:
> reopen 93208 =
> done
> 
> Hi,
> I'm cc'ing the developers of peep. For the history of this bug see:
> http://bugs.debian.org/93208

Ok. Developers, please read this mail and see attached patch as is fixes some
bugs in your code.

> 
> I'd still be interested in seeing a Debian package of peep, the "Network
> Auralizer". Javi, I don't understand what you mean by "for
> log-interpretation I do prefer log-analys/logcheck". Can these be made
> to output sounds?

No, it's just that (admin-wise) peep is not really that much useful. It's
fancy, but not that useful.

> If anyone knows of a better "auralizer" that I could use for network/log
> events, please let me know. I'd be happy to find a less complicated
> alternative to peep (and thus have reason to re-close the request for
> package bug 93208).

I'm not aware of any.

> Upstream development is stalled. The developers are responsive, but it
> seems they don't have time to do many new developments [1]. I believe
> they can be convinced to help out with licensing or compilation problems.

Understood. Attached is a patch which can be used to build a Debian package
out of Peep and fixes a number of bugs in the latest release. If you don't 
know how to use it I could upload packages to people.debian.org/~jfs

I just don't want to maintain more packages, so it would be best if you
found a suitable maintainer for these. I can make the initial upload,
however.

Regards

Javier
--- peep-0.5.0-rc2.orig/server/cmdline.c
+++ peep-0.5.0-rc2/server/cmdline.c
@@ -316,7 +316,7 @@
 {
 
printVersion ();
-   printf ("
+   printf ("\
 Usage: %s [OPTIONS]...\n\
-h --helpPrint help and exit\n\
-V --version Print version and exit\n\
--- peep-0.5.0-rc2.orig/server/debug.c
+++ peep-0.5.0-rc2/server/debug.c
@@ -18,6 +18,9 @@
 
 #include "config.h"
 #include 
+#include 
+#include 
+#include 
 #include "debug.h"
 
 /* For time formatting */
@@ -83,7 +86,7 @@
 
if (fclose (log_handle) != 0)
perror ("Error closing server log file");
-
+   return 0;
 }
 
 void log (int level, char *s, ...)
--- peep-0.5.0-rc2.orig/server/main.c
+++ peep-0.5.0-rc2/server/main.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "main.h"
 #include "cmdline.h"
@@ -30,6 +31,7 @@
 #include "mixer.h"
 #include "playback.h"
 #include "debug.h"
+#include "parser.h"
 
 static struct args_info args_info;
 static FILE *pid_file = NULL;
@@ -84,7 +86,7 @@
else {
 
/* Write our pid out to the file */
-   fprintf (pid_file, "%d\n", pid_file);
+   fprintf (pid_file, "%d\n", pid);
fflush (pid_file);
fclose (pid_file);
 
@@ -271,6 +273,8 @@
 
}
 
+   /* Should really return something useful here */
+   return 1;
 }
 
 void printGreeting (void)
--- peep-0.5.0-rc2.orig/server/thread.h
+++ peep-0.5.0-rc2/server/thread.h
@@ -19,6 +19,7 @@
 #ifndef __PEEP_THREAD_H__
 #define __PEEP_THREAD_H__
 
+#include 
 #include 
 #include 
 
--- peep-0.5.0-rc2.orig/debian/changelog
+++ peep-0.5.0-rc2/debian/changelog
@@ -0,0 +1,11 @@
+peep (0.5.0-rc2-1) unstable; urgency=low
+
+  * Initial release Closes: #93208
+  * Fixed compilation error in cmdline
+  * Fixed compilation warnings due to some libraries not being included
+and an error in the pidfile generation (the pid was not added to the
+file)
+  * Provide an init.d and logrotate.d configuration files (UNTESTED)
+
+ -- Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>  Thu, 29 Sep 2005 
21:19:16 +0200
+
--- peep-0.5.0-rc2.orig/debian/compat
+++ peep-0.5.0-rc2/debian/compat
@@ -0,0 +1 @@
+4
--- peep-0.5.0-rc2.orig/debian/peep.init
+++ peep-0.5.0-rc2/debian/peep.init
@@ -0,0 +1,112 @@
+#! /bin/sh
+#
+# peep  Start the sound server
+#
+# Author:   Devin
+# Modified for Debian by Javier Fernandez-Sanguino Peña
+#
+# description: Kickass Sound Server and network / log monitor
+# processname: peepd
+# pidfile: $RUNDIR/peepd.pid
+# config: /etc/default/peep
+# config: /etc/peep.conf
+
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+DAEMON=/usr/sbin/peep
+NAME=peep
+DESC="PEEP server"
+LOGDIR=/var/log/peep
+LOCKDIR=/var/lock/peep
+RUNDIR=/var/run/peep
+ARGS="-l $LOGDIR/$NAME.log"
+
+test -x $DAEMON || exit 0
+
+# Include peep defaults if available
+if [ -f /etc/default/peep ] ; then
+   . /etc/default/peep
+fi
+
+set -e
+
+RETVAL=0
+
+running()
+{
+# No pidfile, probably no daemon present
+#
+[ ! -f "$PIDFILE" ] && return 1
+pid=`cat $PIDFILE`
+# No pid, probably no daemon present
+[ -z "$pid" ] && return 1
+[ ! -d /proc/$pid ] &&  return 1
+cmd=`cat /proc/$pid/cmdline | tr "\000" "\n"|head -n 1 |cut -d : -f 1`
+# TODO: This might be more portable than looking for /proc/pid/
+# if p

Bug#332858: ITP: cvsup -- The CVS-Optimized General-Purpose Network File Distribution System

[Javier Fernández-Sanguino Peña]

On Sun, Oct 09, 2005 at 01:03:38PM +0300, George Danchev wrote:
> On Sunday 09 October 2005 03:10, Henning Makholm wrote:
> --cut--
> > > The CVSup requires Modula-3 compilator to build, so also I'm
> > > planning to package Ezm3 - An Easier Modula-3 Distribution, which is
> > > designated to compile CVSup only.
> >
> > Best of luck with that. Torsten might still be interested, too.
> 
> CVSync [1] is a possible alternative to CVSup, not compatible with it, but 
> written in plain C.

That one looks interesting, I did not find it when I was googling for
alternatives to CVSup. I would love to see something like this packaged so
that we could distribute copies of our CVS worlwide and not have issues if
we have any issues with the servers holding our CVS in the future.

Regards

Javier


signature.asc
Description: Digital signature

Bug#160005: ITP: snare -- SNARE graphical user interface

[Javier Fernández-Sanguino Peña]

On Sat, Sep 07, 2002 at 05:14:52PM +, Michelle Ribeiro wrote:
> Package: wnpp
> Version: N/A; reported 2002-09-07
> Severity: wishlist
> 
Why not checking the wnpp first? (Bug #125657)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=125657&repeatmerged=yes

Granted, it's taken me a while to package it. Feel free to close *both*
bugs (probably you should merge them too).

Javi

Bug#82613: Crack license, is it free?

[Javier Fernández-Sanguino Peña]

On Mon, Sep 09, 2002 at 11:20:05AM +0100, Colin Watson wrote:
> > 
> > The give away here may be problematic, however see below:
> > > 5.  You may charge a reasonable copying fee for any distribution of this
> > > Package.  You may charge any fee you choose for support of this Package.
> > > YOU MAY NOT CHARGE A FEE FOR THIS PACKAGE ITSELF.  However, you may
> > > distribute this Package in aggregate with other (possibly commercial)
> > > programs as part of a larger (possibly commercial) software distribution
> > > provided that YOU DO NOT ADVERTISE this package as a product of your
> > > own.
> > 
> > This is decidedly not DFSG free, it can go in non-free but it can't go
> > in main.
> 
> This is all just straight out of the Artistic License. DFSG 1 only says
> that you can't prohibit selling software as a component of a
> distribution, not that you can't prohibit charging for the package
> itself.
> 

Yes, from the Artistic License:

5. You may charge a reasonable copying fee for any distribution of this
Package.  You may charge any fee you choose for support of this
Package.  You may not charge a fee for this Package itself.  However,
you may distribute this Package in aggregate with other (possibly
commercial) programs as part of a larger (possibly commercial) software
distribution provided that you do not advertise this Package as a
product of your own.  You may embed this Package's interpreter within
an executable of yours (by linking); this shall be construed as a mere
form of aggregation, provided that the complete Standard Version of the
interpreter is so embedded.

Javi

Bug#123250: Mozilla-local-es-{es,ar,hn} packages for Debian

[Javier Fernández-Sanguino Peña]

What state is currently the mozilla-locale-es packages made by you Eric?
This bug is still open and I, just yesterday, made packages to fix this
(not knowing that you were already working on them).
The packages currently provide localisation for Argentina and Latin
America (derived from Mozillas' pages) and for Spain (from the NAVE
project). Since there are some common files (es_unix.jar) I have made them
all Provide: mozilla-local-es and Conflict: between them.

The packages for es-AR and es-HN work fine but the es-ES one doesn't (I'm
however using Mozilla 1.0.0 and the Xpi is for 0.95). Please, take a look
at them, let's see if we can fix this stuff together:

http://www.dat.etsit.upm.es/~jfs/debian/DO/mozilla-locale-es/

Regards

Javi


pgpPGIca5qRJT.pgp
Description: PGP signature

Bug#93208: Peep available anywhere?

[Javier Fernández-Sanguino Peña]

 Joey Hess said:
>How's the packahing of peep coming? I'd love to try some experimental
>debs out.


/me too. Just a note, however. Peep has changed both name and location.
It's now called 'Network Auralizer' and is available at 
http://www.auralizer.com:8080/peep/index_html
or http://www.auralizer.com  for short.

The old page (at sourceforge) [1] mentioned that it was being packaged for
Debian (dated October 23rd, 2001):
> In other news, Peep is currently being packaged for Debian and all
> things willing, will appeared in Debian 3.0 ("woody"). So packages  are
> on the way for you debian users :)

Which seems to not be the case. Please, could you change this into an
'RFP' if you are not going to package peep. If you are having problems,
please say so in the bug report, it doesn't look that difficul to package
(I will try to, and if I make the packages I *will* send it to Debian)

Regards

Javi



[1]
http://216.239.39.100/search?q=cache:K0GUWLVWzygC:peep.sourceforge.net/+auralizer+debian+packages&hl=es&ie=UTF-8
 




pgpP9mxYc1jNt.pgp
Description: PGP signature

Bug#93208: Preliminary packages available for 'peep'

[Javier Fernández-Sanguino Peña]

As promised, there are preliminary packages available for peep and
peep-sounds at www.dat.etsit.upm.es/~jfs/debian/applications/peep

Tv, David, Joey, could you please test these packages? They seem to work
mostly fine, although there are some issues pending (such as licensing,
for example, for peep sounds :(

I have not tested them thoroughly (to see if they play sounds, for
example)... but the daemons start/stop mostly ok..

Regards

Javi


pgpNTQRp9RdeG.pgp
Description: PGP signature

Bug#93208: Preliminary packages available for 'peep'

[Javier Fernández-Sanguino Peña]

>   I don't remember hard issues with the sounds' license. Are you sure 
> they're 
> not DFSG-compliant?
> 
They have no license whatsoever in the distributed tar.gz. That's
the problem.

Regards

Javi


pgpem1ePPBK15.pgp
Description: PGP signature

Bug#93208: Preliminary packages available for 'peep'

[Javier Fernández-Sanguino Peña]

Sorry to answer late, I have been doing other stuff.

On Mon, Oct 21, 2002 at 09:19:55PM -0400, Joey Hess wrote:
> Javier Fernández-Sanguino Peña wrote:
> 
> Well I get a usage message on peep install:
(...)

I have fixed this issues. The new packages (I have not changed the
version BTW) do the startup just fine. Or at least the logs show up
properly.

(..)
> ...
> 
> I tried some programs like peck and keytest but have not heard a peep out
> of it yet.
> 
> Hmm, I have this in peepd.log:
> 
> Couldn't find peep.conf at: /usr/etc/peep.conf
> Uh Oh! peep.conf not properly configured or error loading sound files
> 
> Linking /etc/ to /usr/etc makes the init script work, but still no sound.
> 
I have not been able to make it send sounds (but that might be due
to an unconfigured sound card). In any case, I've somewhat lost interest
in the package, I expected it to use the packets that were being received
in the network interface as a source of sounds, but I see (digging into
the code) that currently there is only a log interpreter.

It turns out that the only think interesting currently is the
dynamic sound mixing module, which looks quite good. However, for
log-interpretation I do prefer log-analys/logcheck. I just thought it
would base the sounds on packets (setting the card on promiscuous mode)
not on logs. Oh well.

The new packages work for me (I mean that they start/stop
corrently and the logs look fine, no sound though). I haven't played with
it, feel free to take over and try to make them work :)

Javi

PS: Available in the same place:
www.dat.etsit.upm.es/~jfs/debian/applications/peep


pgpZWKmkgKNjg.pgp
Description: PGP signature

Bug#93368: Sara packages might not be license compatible

[Javier Fernández-Sanguino Peña]

Just to add more information for the curius: Sara is not properly licensed.
It was rejected from the archive's upload queue August 2002 by aj:

>>>
``This program is *not* free software since no fee (other than
 "at-cost") can be charged for its distribution (see note below);
 SARA changes to the SATAN code base, although GPL, cannot make
 this package go into main/free.''
 .
 This doesn't work -- if your original codebase wasn't DFSG-free (and
 GPL compatible), then you can't distribute modifications based on GPLed
 changes. Talk to -legal about your options from here.


Sara packages are availabe in the same place I mentioned but, for the 
moment, it will not be included in Debian.

I still have to discuss at debian-legal (and with Sara's team for that
matter) the licensing issues. But AFAIK Dan Farmer and/or Wietse Venema
will not change SATAN's original license and this means that either
Sara's team rewrites the Satan code base or it can never be included
into main (it could maybe be included into contrib by depending on
satan and patching it, or, otherwise, in non-free)

Regards

Javi


pgp70RjmeMXOv.pgp
Description: PGP signature

Bug#173061: ITP: Titan - security hardening and audit

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A; reported 2002-12-14
Severity: wishlist

  Package name: titan
  Version : 4.0 (beta 6)
  Upstream Author : Brad M. Powell, Dan Farmer, and Matthew Archibald
  URL : http://www.fish.com/titan
  License : based on Artistic License (asked in debian-legal and
ok)
  Description : Security hardening and audit modular tool

From the HTML pages:
   Titan is a collection of programs, each of which either fixes or
   tightens one or more potential security problems with a particular
   aspect in the setup or configuration of a Unix system. Conceived
   and created by Brad Powell, it was written in Bourne shell, and
   its simple modular design makes it trivial for anyone who can
   write a shell script or program to add to it, as well completely
   understand the internal workings of the system.
   Titan does not replace other security tools, but when used in
   combination with them it can help make the transformation of a
   new, out of the box system into a firewall or security conscious
   system into a significantly easier task. In a nutshell, it
   attempts to help improve the security of the system it runs on.
(...)
   Titan can help with all of these problems; its main design goals are:


 * After being run, the system should be more secure than when we
   started. Things may be broken, but it should be more secure! The
   truth is that most things you do to secure a system are probably
   not going to cause a problem. A vendor can't take that chance -
   but we can. In any case, we haven't run into anything that Titan
   has broken, but it certainly could happen.
(...)
 * Producing a consistent and understandably secure system.
(...)

Titan has recently (?) changed from a non-free license to use the Artistic
License. I considered packaging Titan at the time but dismissed it due to
its license. I will package it now.

Titan is a mixture of what Bastille and Tiger provide currently for
Debian. On one hand it can automatically secure a system (however, it's
less "verbose" that Bastille) on the other, it can check if the system is
secure (like Tiger does).

Javier Fernandez-Sanguino Peña


pgpqYnBMXTBe8.pgp
Description: PGP signature

Bug#173443: ITP: honeyd

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A; reported 2002-12-16
Severity: wishlist

Package name: honeyd
Version : 0.4
Upstream author : Niels Provos
URL : http://www.citi.umich.edu/u/provos/honeyd/
License : DFSG-free (with advertisement clause, GPL-incompatible,
see below)
Description : Small daemon that creates virtual hosts simulating their 
services and behaviour

Long description:
(From the freshmeat page:
http://freshmeat.net/projects/honeyd)

Honeyd is a small daemon that creates virtual hosts on a network. The
hosts can be configured to run arbitrary services, and their TCP
personality can be adapted so that they appear to be running certain
versions of operating systems. Honeyd enables a single host to claim
multiple addresses on a LAN for network simulation. It is possible to ping
the virtual machines, or to traceroute them. Any type of service on the
virtual machine can be simulated according to a simple configuration file.
Instead of simulating a service, it is also possible to proxy it to
another machine. 


LICENSE:

/*
 * Copyright 2002 Niels Provos <[EMAIL PROTECTED]>
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *must display the following acknowledgement:
 *  This product includes software developed by Niels Provos.
 * 4. The name of the author may not be used to endorse or promote products
 *derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
 * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

Ž
Regards

Javi


pgpB68pXtr3o8.pgp
Description: PGP signature

Bug#173443: Packages now available for testing purposes

[Javier Fernández-Sanguino Peña]

Packages of honeyd are now availabe for testing at:

http://www.dat.etsit.upm.es/~jfs/debian/security/DO/honeyd/

Feel free to test it and submit suggestions to me. I'm waiting for the 
upstream maintainer to give the final 'go'.

Regards

Javi


pgpr0QhvwlUxN.pgp
Description: PGP signature

Bug#125657: Test offering of development version of SNARE subsystem

[Javier Fernández-Sanguino Peña]

Dear Leight and George,

I have been following with intersted the development of the SNARE audit
subsystem for Linux. As a Debian maintainer I have been wanting to
integrate this subsystem in Debian and provide it as a package in the
distribution (please see http://bugs.debian.org/125657)

However I have not had time to work with the kernel module but, since there
is a development version which "works" with 2.4.18 and later I would be
interested in giving it a try. Could you please send me the latest
development version?

I'm CCing Andrew Lau since he is alread interested in packaging Snare for
Debian too, and the Debian BTS to keep it uptodate to the latest state of
this issue.

Best regards


Javier Fernandez-Sanguino

PS: For the time being, I have only Debian packages ready for the frontend
of Snare (0.8 version). And they are currently available at
http://www.dat.etsit.upm.es/~jfs/debian/security/DO/snare


pgpAzRH6rtjrn.pgp
Description: PGP signature

Bug#183098: O: log_analysis -- log analysis tool is now orphaned

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A
Priority: normal

I have just uploaded and orphaned log_analysis, after closing the open bug
reports and upgrading to the latest upstream release. I'm unable to
maintain it and I believe someone else should take better care of it, if
appropiate.

Log_analysis functions are done already by 'logcheck' and the latest has a
better and more uptodate list of signatures in logs. Also, some other of
its functions (wtmp analysis) are implemented by sac too. However, some of
its features (configurable log tests) are not present in other software.

If someone should take over he should cooperate with upstream to make it
easier to integrate with the log patterns database provided by logcheck. 

Regards

Javier Fernandez-Sanguino


pgpGG77wk3d1L.pgp
Description: PGP signature

Bug#183100: O: tcltutor -- tutor for Tcl/TK orphaned

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A
Priority: normal

I have just uploaded and orphaned tcltutor. This package should be taken by
someone with more knowledge on Tcl/Tk than myself since many of the open
bugs are related issues.

Also, notice that this package seems to be almost dead upstream (it has not
moved from version 2b4 in quite some time). I believe it could be feasible
(if someone took the time of pestering upstream) to change its license and
move it from non-free to main. This is a very useful package (at least for
those that do not know Tcl/Tk).

Note that the bugs fixed in the program have not been submitted upstream
due to my lack of time, but they should be integrated there. Also, they
could be shown as how having it in Debian has made people test it and
submit bugs that eventually have been fixed. Oh, the wonders of (almost-)
free software :-) 


Regards

Javier Fernandez-Sanguino



pgp830cpRCz0k.pgp
Description: PGP signature

Bug#292019: removal judgement for binstats

[Javier Fernández-Sanguino Peña]

On Thu, Feb 24, 2005 at 05:51:36PM +0100, Gaudenz Steinlin wrote:
> Hi Javier
> 
(...)
> 
> Below you find my report about binstats. Your package makejail depends
> on binstats and I wanted to ask you if you would like to adopt it.

Let me review the current status. I will probably adopt it.

Thanks for the info.

Regards

Javier


signature.asc
Description: Digital signature

Bug#301700: ITP: update-manager -- a GNOME application that manages apt updates

[Javier Fernández-Sanguino Peña]

On Sun, Mar 27, 2005 at 05:01:34PM -0300, Andre Filipe de Assuncao e Brito 
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Andre Filipe de Assuncao e Brito <[EMAIL PROTECTED]>
> 
> * Package name: update-manager
>   Version : 0.37.1
>   Upstream Author : Michiel Sikkes <[EMAIL PROTECTED]>
> * URL : http://geeklog.eyesopened.nl/index.php/update-manager/
  
Sorry, 404 here.

> This is the GNOME apt update manager. It checks for updates and 
> lets the user choose which to install.

Is this similar to Red Hat's rhn-applet or Apt-watch? [1] I found about 
this last one "the hard way" (that is, after porting Red Hat's appled to 
Debian and have it support apt...)

Regards

Javier


[1] http://lists.debian.org/debian-desktop/2004/03/msg9.html


signature.asc
Description: Digital signature

Bug#173061: Update on this package's ITP

[Javier Fernández-Sanguino Peña]

Just an update on this ITP. 

I have recently packaged and uploaded titan-tools, which provides the tools 
developed by the upstream maitainers of Titan (noshell and runas). However, 
since I have not seen that much interested for Bastille (few bug reports 
and low ranking in the popularity contest) I'm holding off uploading Titan.

Also, the license changes,  even if the web page [1] states the license is 
based on the Artistic License, the LICENSE.txt file of the 4.1 and 4.2 
releases still say:

-
1. NON-COMMERCIAL USE
 
 You may not sell Titan  nor sell any of the functionality it provides.
 No part of Titan may be used as part of any commercial product or service
 without having first obtained a commercial licence from Team Titan.

(...)

3. REDISTRIBUTION
 
This software may not be redistributed without prior written permission 
from
 
Team Titan. You may make coppies for your own use, but not redistribute.

(...)
Last Modified Wed June 14 14:28:21 PST 2001
-

Wether they plan to fix this or not I really don't know (and have not 
pursued it), but it makes it non-free and, as such, I really don't want to 
waste too much time packaging it

If anyone wants to take over, please say so, I'm too busy to 
work solving this ITP atm.

Javi


[1] http://www.fish.com/titan/


signature.asc
Description: Digital signature

Bug#93368: Update on this ITP

[Javier Fernández-Sanguino Peña]

Some information related to this ITP:

- Packages are no longer available at the location I mentioned, if you want 
them, please ask.

- The current homepage for SARA is http://www-arc.com/sara/

- it is currently at version 5.0

Since this software is based on SATAN, and after giving the matter some
thought, I'm considering it fully non-free.  Thus, I'm holding off any
attempts to make a new package (I prefer to focus my work in improving the
Nessus packages), if somebody wants to take over this ITP, please say so.

Also notice that whomever works on this package needs to do changes to the 
source code to follow the following (from the COPYING file):

"Changes to this code are permitted but the derived work shall not contain 
the name SARA in any reports, either electronic or hardcopy."

Regards

Javi



signature.asc
Description: Digital signature

Bug#232127: RFP: logwatch -- system log analysis utility

[Javier Fernández-Sanguino Peña]

On Wed, Feb 11, 2004 at 02:22:19AM +, Jay Berkenbilt wrote:
> 
> Logwatch is a collection of perl scripts that analyze system logs and
> email summaries to system administrators.  It can provide a very
> useful early-warning system, especially for people who may not read
> through all their system logs every day.

Yes, but that's quite similar a function  to what logcheck does. It would 
be nice if you could describe any benefit of using logwatch vs. logcheck 
too (in the Description).

> 
> I've been using logwatch for some time on Red Hat-based systems and
> would like to use it on my Debian systems as well.  If no one else is
(...)
> up somewhere and request a sponsor on debian-mentors.  I have not yet
> done any work on this; I have merely observed that logwatch does not
> appear to be present in Debian and has not apparently been requested
> either.

That's probably because most users use logcheck [1] which provides an 
extensible mechanism to mail just parts of the syslog. It does not do 
summaries of information (as logwatch does), however. Shouldn't it be 
better to integrate this functionality in logcheck?

In any case, I would gladly accept suggestions on the current (brief)
description of log-analysis checking and  tools in the Securing Debian 
Manual:
http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s-log-alerts

Regards

Javi


[1] http://popcon.debian.org shows that logcheck is ranked quite high vs 
other alternatives such as syslog-summary, log-analysis, logtool, log2mail
or even fw specific: fwlogwatch, fwanalog, logwatch...


signature.asc
Description: Digital signature

Bug#216878: yale and gliese

[Javier Fernández-Sanguino Peña]

On Tue, Feb 24, 2004 at 10:12:39PM +0100, Gabriel Rodríguez Alberich wrote:
> I'm about to apply as a NM and would like to adopt yale and gliese for a 
> sponsored upload. They seem quite simple (little or none upstream activity 
> and lintian cleannness, as you said).
> 

Yep. Easy maintenance, but as I said in the O: I would like that the person 
that takes this over took starplot, and spacechart too (openuniverse is 
also in the "bag" even if it's not O: yet)

However, Aaron Bloomfield <[EMAIL PROTECTED]> offered first to do so 
a while back (January 14th) I'm ccing him so you both talk it out.

> I'm aware of your wish of integrating the use of astronomical data of the 
> different GUIs present in Debian to avoid redundancy.

Yep, there should be some more pro-active work in that area in order to 
avoid bloateness and to detect packages that are using non-DFSG free data, 
I've filed some bugs related to this, like #225002 or #174456.

You should also consider this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=233425
(a similar issue)

> Thanks :)

You are welcome :-)

Javi


signature.asc
Description: Digital signature

Bug#173061: Update on this bug status

[Javier Fernández-Sanguino Peña]

Just an update on this bug (which has been opened for quite some time 
already). I was contacted (in January of this year) by Matthew Archibald 
related to the runas/noshell port of Titan's tools to Debian (which are in 
the titantools package)  and I took the opportunity to discuss Titan 
licensing.

Until I get an update on why there are discrepancies between the web site
license and the one in the source code itself, Titan should be considered
non-free (but could be distributed there since there are only limits to
commercial redistribution or usage). I will rather not support another
non-free package myself so I will hold off an upload of the package until I
get a confirmation on wether it's free or not (if it turns out it is not, I
will probably just close this ITP)


Javier


signature.asc
Description: Digital signature

Bug#244094: ITP: gradm2 -- Administration program for the GrSecurity ACL system (GrSec 2)

[Javier Fernández-Sanguino Peña]

On Fri, Apr 16, 2004 at 12:18:34PM -0400, andrew lattis wrote:
> 
> * Package name: gradm2
(...)
> 
> Administration program for the GrSecurity ACL system gradm is used to
> manage the ACL system of GrSecurity.

Are you aware that (in the WNPP)

   gradm (#240252), orphaned 20 days ago
 Description: Administration program for the GrSecurity ACL system

   kernel-patch-2.4-grsecurity (#240253), orphaned 20 days ago

Is it really necessary to have a gradm2 package or could you update the 
gradm package? It would be also nice if you could take over maintership of 
the kernel-patch itself. 

Regards

Javier


signature.asc
Description: Digital signature

Bug#216874: Situation of astronomical packages, ITA offer and proposed RFC

[Javier Fernández-Sanguino Peña]

On Sat, Apr 17, 2004 at 03:05:58PM -0400, Kevin B. McCarty wrote:
> Hi Javi and others,

Hi there.

> As no one else has volunteered, I'd be interested in adopting starplot 
> and spacechart.  I would very much like to help disentangle the mess of 
> redundant data and licensing problems with the astronomy-related 
> packages in Debian.  Full disclosure: I am the upstream author for 
> starplot; hope that isn't considered a conflict of interest.  I plan to 
> start the NM process after having my GPG key signed next weekend, so I 
> will need a sponsor to upload packages for now.

There has been one volunteer (it's just not in the BTS info):
Francisco García <[EMAIL PROTECTED]>
(in CC)

I have not yet been able to review his packages (up at
http://usuarios.lycos.es/franciscogarciac/debian/). But I would appreciate 
it you contacted him and considered co-maintaining those packages.

> Aaron and Gabriel: what is the status of your ITA for the gliese and 
> yale packages?  If you are still interested in adopting them, great; if 
> not, I have no problem taking those on as well.  I would also be 
> interested in packaging the Hipparcos catalogue, since it seems to be 
> DFSG-free (public domain) from the discussions in bugs # 198495, 174456, 
> 198499.

Great.

> 
> Here are my latest thoughts on the matter of packaging, sort of a 
> mini-RFC.  Let me know what you think:
> 
> 0) I suggest that each star data package be named stardata-, e.g. 
> stardata-gliese, to make it easy for users to find them.  (This need 
> only apply to the binary Debian package name, not the source package.) 
> If so, please read  for  in all the following 
> points.  And they should probably all go in the "science" or 
> "{contrib,non-free}/science" sections, as well as all the astronomy 
> programs.

Sounds ok.

> 
> 1) Each star data package should put all of the upstream materials in 
> /usr/share/stardata// (for data and descriptions of data 
> format) or /usr/share/doc// (for readmes, copyrights, etc.)

Sounds good.

> 
> 2) The actual ASCII data file should be named 
> /usr/share/stardata//catalog.dat (with a symlink, if 
> desired).  If there are more than one data file, either call them 
> catalog1.dat, catalog2.dat, ... or else merge them.  If there are more 
> than nine data files, call them catalog01.data, ..., catalog10.dat, ... 
> so that they are collated in the correct order.  Similarly 
> catalog001.dat for more than 99 files, etc.  (I am willing to be 
> persuaded that the numbering should start at 0 instead of 1.)

Sounds good.

> 
> 3) Each program that can use a star data file should Depends, Recommends 
> or Suggests the appropriate data package.  If the program will fail when 
> the data file is not found, of course it must use the Depends 
> relationship.  If the data package is in non-free and the program is in 
> main, the program must (per Policy) only use Suggests.  Therefore any 
> program that requires a non-free data file to run must itself be in 
> contrib or non-free.

Correct.

> 
> 4) Each program that can use the data file directly (celestia, 
> spacechart, ...) should either
>   a) be patched to look for the data file(s) in the place noted above;
>   b) be packaged with symlinks to the data file(s), but then it must
>  Depend on the packages for those data file(s) in order to avoid
>  broken symlinks; or else
>   c) generate symlinks at install time, but then the program is subject
>  to the conditions (5a) and (5b) below in order to avoid broken
>  symlinks.

Notice that if you removed the startdata stuff but installed a package that
was using c) then you would end up with a program that does not work. I 
think that c) should be ruled out.

> 
> 5) Each program that requires some preprocessing of a data file before 
> using it (I think starplot is the only such program) should:

Some other programs use modified versions of the star data catalogues but 
do not provide preprocessors to regenerate the data IIRC.

>   a) include a packaged binary or script to do the preprocessing
>   b) rerun the preprocessing whenever the program or any of the data
>  files it can use are installed or removed.  This means that the
>  maintainer of the program will need to ask the maintainer of the
>  data files to include preprocessing hooks in their postinst/prerm
>  scripts.  A preprocessed data file should be deleted when the
>  corresponding star data package is uninstalled.  ALL preprocessed
>  data files for that program should be removed when the program is
>  uninstalled.  This is similar to how all the mozilla-related
>  packages call "update-mozilla-chrome" on postinst or prerm.

Why remove the stardata if you have already preprocessed it? I don't think 
that's really necessary. However, there is a reason for doing it in the 
stardata catalogues instead of doing it in the programs themselves: it's 
necessary in order to be able to install the stardata catalogu

Bug#216878: Situation of astronomical packages, ITA offer and proposed RFC

[Javier Fernández-Sanguino Peña]

On Mon, Apr 19, 2004 at 09:37:33AM -0400, Kevin B. McCarty wrote:
> > Some other programs use modified versions of the star data catalogues but 
> > do not provide preprocessors to regenerate the data IIRC.
> 
> Well, if it's not too hard to write such a preprocessor to massage the
> data into that program's preferred form, it ought to be done.  If it
(...)

Agreed.

> > Why remove the stardata if you have already preprocessed it? I don't think 
> > that's really necessary.
> 
> It is probably not necessary, but it seems like what an admin would
> expect.  That is, if he uninstalls "gliese", then he probably no longer
> wants the version of the Gliese catalogue modified for starplot, and
> expects that it also would be removed.  Just IMO.

Yes. But that can only be done if the package in charge of generating the 
data is the stardata catalogue program. If the script is run by the 
astronomy package (starplot) then it should not be removed by gliese (since 
those are files of a different package)

> > I'm not sure if /usr/share is better than /var/lib. 
> 
> So you prefer /var/lib?

I really don't have a preference. FSSTND should be checked for the 
appropiate location.

(..)
> I'll send you a new draft of the astro-policy RFC today or tomorrow.
> best regards,

Great. Regards.


Javier


signature.asc
Description: Digital signature

Bug#289168: ITP: xvidcap - Capture X-windows display to frames or video

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A; reported 7-Jan-2005

Package name: xvidcap
Version : 1.1.3
Upstream Author : original code by Gmelch , extended by 
  Karl H. Beckers 
URL : http://xvidcap.sourceforge.net/
License : GPL
Description : (see below)

Package: xvidcap
Architecture: any
Depends: imagemgick, ${shlibs:Depends}
Description: Capture X-windows display to frames or video
 Xvidcap is a screen capture application that can capture
 videos from an XFree86 desktop for illustration or documentation
 purposes. It is intended to be a standards-based alternative to
 propietary tools.
 .
 Xvidcap is still under development, and is not yet fully polished.
 Audio suport, for example, is still under experimental development.
 Nevertheless it is useful for teaching and training through
 video screen captures. You can use the animate program (ImageMagick)
 to view the recorded frames as an animation.
 .
 Xvidcap uses an on-line encoding facility using FFMPEG's libavcodec -
 libavformat.
 .
 Homepage: http://xvidcap.sourceforge.net/


I'm still testing the packages I've built, which seem to work fine with 
imagemagick (to produce animations) but I have not yet tested them with 
FFMPEG.

Regards

Javier


signature.asc
Description: Digital signature

Bug#268910: Xpaint 2.7.0 packages built and tested, should I NMU?

[Javier Fernández-Sanguino Peña]

On Tue, Jan 04, 2005 at 03:58:56PM +0100, Florian Ernst wrote:
> Hello Javier,
> 
> I read in  you were going to NMU
> xpaint. Do you still have any plans regarding this?
> 

No, I don't. I actually don't know where I dropped those.

> If not I'd like to take over (together with Hugo Vanwoerkom) by
> packaging the newest upstream release, now that the package has been
> orphaned for quite some time...

Please do.

Regards

Javier


signature.asc
Description: Digital signature

Bug#323855: ITP: opencvs -- OpenBSD CVS implementation with special emphasis in security

[Javier Fernández-Sanguino Peña]

On Thu, Aug 18, 2005 at 07:31:38PM -0400, Roberto C. Sanchez wrote:
> > > most popular open source revision control software.
> > 
> > And among the most horrible ones.
> > 
> Agreed.  Why anyone would bother to reimplement an already existing free
> tool is beyond me.

For several reasons, one being that the BSD folks use CVS extensively, it's
part of how the ports system (and upgrades) work. 

> Not only that, but the stated purpose of OpenCVS, AIUI, is to be a
> reimplementation of CVS under the BSD license.  It makes no sense to try
> and have both in Debian.  I also agree with you that there are far
> better alternatives.

It does make sense, there are some features (like CVS syncing, which is 
useful for remote backups) that OpenCVS *might* (I haven't looked) implement
straight out of the box and that the current CVS lacks.

Also notice that some of our services (web pages, documentation project)
use CVS and will do so for a long time. Having a CVS server available to
switch to if a security issue in the current standard CVS server is found
is something that would be useful to prevent downtime of those services
if the debian admins have to switch them off.

I say go for it.

Javier


signature.asc
Description: Digital signature

Bug#325289: ITP: debian-hebrew -- Hebrew support in the Debian desktop

[Javier Fernández-Sanguino Peña]

On Sat, Aug 27, 2005 at 02:14:45PM +0200, José Luis Tallón wrote:
> Lior Kaplan wrote:
> 
> >Package: wnpp
> >Severity: wishlist
> >Owner: Lior Kaplan <[EMAIL PROTECTED]>
> >
> >* Package name: debian-hebrew
> >  Version : 1.0.5
> >  Upstream Author : Yaacov Zamir <[EMAIL PROTECTED]>
> >* URL : http://debian-hebrew.alioth.debian.org
> >* License : GPL
> >  Description : Hebrew support in the Debian desktop
> >
> > This meta package will install Hebrew desktop related Debian
> > packages for use by Hebrew debian users.
> > .
> > It also includes a script 'hebrew-settings' to reconfigure
> > the system to have a fully Hebrew-ized desktop.
> > .
> > Homepage: http://debian-hebrew.alioth.debian.org/
> >  
> >
> Hmm... wouldn't it be better to call it "user-hebrew", just like
> "user-euro-es", for example??
> Basically, so as to avoid namespace pollution and potential confussion
> among users

Better yet, the metapackage should be intregrated in tasksel and the 
script should be adapted to work inside localization-config. User-euro-es
is a (bad) hack.

Regards

Javier


signature.asc
Description: Digital signature

Bug#265343: ITA: snort -- Flexible Network Intrusion Detection System

[Javier Fernández-Sanguino Peña]

retitle 265343 ITA: snort -- Flexible Network Intrusion Detection System
thanks

Since I use this package intensively and keep updated backports of it (see 
people.debian.org/~jfs/snort) I intend to adopt this package. Team 
maintenance would be best, if there is sufficient interest I will try to 
allocate time to setup a project at Alioth and move all the code there.

Regards

Javier


signature.asc
Description: Digital signature

Bug#219996: Oinkmaster packaged and ready to upload

[Javier Fernández-Sanguino Peña]

Hi there,

There has been no activity related to this bug report since November. Since 
we are near the release and there is no mechanism to update Snort (which I 
intent to adopt in the near future). 

I have been preparing some simple packages for oinkmaster which I will 
upload soon to the archive, unless there is any objection to it. I don't 
clain this package, if Roberto wants to upload modified^Wimproved packages 
afterwards I will give up maintenance of them. My only goal is to keep the 
ball rolling...

Regards

Javier

Bug#279424: ITP: mozilla-firefox-locale-es-es -- Mozilla Firefox Spanish (es-ES) language/region package

[Javier Fernández-Sanguino Peña]

On Wed, Nov 03, 2004 at 01:14:46AM +0100, Cesar Martinez Izquierdo wrote:
> Package: wnpp
> Severity: wishlist
> 
> 
> * Package name: mozilla-firefox-locale-es-es
(...)

Mozilla-firefox-locale-es-es was recently available, but removed from the 
archive since there were no up-to-date translations and it hindered
mozilla-firefox 0.9.x from moving into testing. Please see bug #272770 (in 
which the maintainer, Javier Carranza, asks for its removal and explains 
why)
and also read
http://lists.debian.org/debian-l10n-spanish/2004/10/msg00082.html
http://lists.debian.org/debian-l10n-spanish/2004/10/msg00084.html

The previous packages are available at snapshot.debian.net, and the
original maintainer is willing to provide new packages as soon as the
translations have been update. Could you please contact him to coordinate
efforts?

Regards

Javier


signature.asc
Description: Digital signature

Bug#268910: Xpaint 2.7.0 packages built and tested, should I NMU?

[Javier Fernández-Sanguino Peña]

On Tue, Jan 04, 2005 at 03:58:56PM +0100, Florian Ernst wrote:
> Hello Javier,
> 
> I read in  you were going to NMU
> xpaint. Do you still have any plans regarding this?
> 

No, I don't. I actually don't know where I dropped those.

> If not I'd like to take over (together with Hugo Vanwoerkom) by
> packaging the newest upstream release, now that the package has been
> orphaned for quite some time...

Please do.

Regards

Javier


signature.asc
Description: Digital signature

Bug#361954: [Pkg-ossec-devel] [ossec-dev] OpenSSL exception

[Javier Fernández-Sanguino Peña]

On Wed, Aug 03, 2011 at 11:37:54AM -0300, Daniel Cid wrote:
> So what exactly needs to be added to the license? I will send that to
> the Trend team for addition...

I believe the following text should do it:

"In addition, as a special exception, the copyright holders give permission
to link the code of portions of this program with the OpenSSL library under
certain conditions as described in each individual source file, and
distribute linked combinations including the two.

You must obey the GNU General Public License in all respects for all of the
code used other than OpenSSL. If you modify file(s) with this exception, you
may extend this exception to your version of the file(s), but you are not
obligated to do so. If you do not wish to do so, delete this exception
statement from your version. If you delete this exception statement from all
source files in the program, then also delete it here."

This should be added in the header of source files that link to OpenSSL. See
attached example file (gpl-openssl-header.txt) for a header.

In addition, to clarify the situation, the attached file LICENSE.OpenSSL
could be added to the source code's alongside the LICENSE file

For more information see:
 - http://people.gnome.org/~markmc/openssl-and-the-gpl.html
 - http://lists.debian.org/debian-legal/2004/05/msg00595.html

> Also, OpenSSL doesn't need to be added (and everything should work
> fine). In fact, that's how we support
> systems without openssl-dev installed... We just link to it for small
> performance gains (when generating the
> sha1 hashes).

In OSSEC you are actually embedding OpenSSL code directly, so the exception
is required, regardless of whether (in the build) the code links to the
OpenSSL's system libraries or to the OpenSSL code built from the OpenSSL
code you include.

More specifically, the files src/os_crypto/sha1/md32_common.h,
src/os_crypto/sha1/sha.h, and src/os_crypto/sha1/sha_locl.h seem to come
straight form the OpenSSL library.

This being the case, the license exception needs to be added. If you want to
prevent this exception then you could replace the OpenSSL implementation and
use the GNU TLS library, which provides the same functions you use. This
library is GPL-compatible.

Historically, some projects have decided in the past to move from the OpenSSL
library to the GNU TLS because of these license incompatibilities.


Regards


Javier








signature.asc
Description: Digital signature

Bug#289168: no longer in NEW

[Javier Fernández-Sanguino Peña]

On Mon, Nov 20, 2006 at 02:00:56PM -0700, dann frazier wrote:
> xvidcap no longer appears in NEW:
>   http://qa.debian.org/~anibal/debian-NEW-summary.html
> 
> Was it rejected?

Yes, I have to fix some issues and reupload it. But I have not had time to do
so yet.

Regards

Javier


signature.asc
Description: Digital signature

Bug#390217: New flawfinder release packages ready to upload (co-maintain?)

[Javier Fernández-Sanguino Peña]

Hi guys,

I've seen there are, at least, two people interested in this package.
However, a new release has been made quite recently (1.27, 1 day ago) and no
uploads are forthcoming.

I would be interested in having this version packaged (it provides some new
features I want to try out) and have packages ready to upload. So, is anyone
working on this?

If I don't hear anything in a few days (let's say 5) I'll make the upload and
set myself as Maintainer. I'm, of course, open for co-maintenance of this
package and would actually prefer to be backup maintainer. 

Regards

Javier


signature.asc
Description: Digital signature

Bug#984736: RFH: cron -- new maintainer need

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A; reported 2021-07-03
Severity: wishlist

A new an active maintainer is required for the cron package. Cron is a basic
system utility that runs programs periodically in the system, it is used by
multitude of packages and is part of the core OS debian tools.

The package is maintained in Salsa (https://salsa.debian.org/debian/cron).

I picked up the package in 2005 and have been trying to maintain it and fix
bugs in it and keep it more or less current. In 2014, Christian Kastner
joined as co-maintainer and has been done the bulk of the job in mantaining /
improving it. He recently did a fantastic job in converting the package to
3.0 (quilt).  

He also provided its replacement, cronie, in experimental (package available
at https://salsa.debian.org/debian/cronie, upstream available at
https://github.com/cronie-crond/cronie)

Cron has been dead for years upstream, Debian still uses it instead of Cronie
as over the years the package has received many changes that are
Debian-specific.

Ideally a maintainer willing to help cron move forward would support the next
major task to be done: moving the Debian-specific patches into cronie and 
providing an updated package for cronie replacement that can eventually
replace cron.

Please contact the current maintainer if you can help in maintaining and
improving cron.

Best regards,

Javier Fernández-Sanguino


signature.asc
Description: PGP signature