Bug#740916: ITP: dms -- DNS Management System

[Matthew Grant]

Package: wnpp
Severity: wishlist
Owner: Matthew Grant 

* Package name: dms
  Version : 1.0
  Upstream Author : Matthew Grant 
* URL : http://mattgrant.net.nz/software/dms
* License : GPL3
  Programming Lang: Python
  Description : DNS Management System

DNS Management System using bind9 and PostgresQL 9.2+.  Uses Dynamic
Updates to update and manage the Zones in Bind9.  Has a daemon which
uses a State Machine for publishing zones from the DB.  There is a
command line/shell program zone_tool for operation on the Zones,
including running an editor, and a JSON RPC over http interface via
Apache and mod_wsgi.

oMaster can have DR Failover

oIPv6 fully supported in back end and front end

oIPv6 DNS RRs ()

oDynamic DNS configuration of Master server reduces need for
reconfig and reload operations.

oDNS RRs supported include SOA NS A  MX PTR TXT SPF RP SSHFP SRV
 NSAP NAPTR LOC KX IPSECKEY HINFO CERT DS. DNSSEC handled by bind9 master

oAuto DNSSEC via Bind9 dynamic DNS. Bind9 master server auto
 maintains zone DNSSEC operations records and signing. NSEC3 and NSEC
 supported. DNSSEC key management on Master server file system pending
 write of key management module. Key material directory is replicated via
 DR protocol (rsync) though. DMS is fully enabled to use DNSSEC for
 securing our core domains.

o   Apex resource record (SOA and NS) management across all zones - can
be turned off per zone.

o   Auto reverse PTR generation

o   Customer control of their own automated reverse DNS. Individual PTR
records, and complete reverse zones. Useful for business IPv6 and IPv4
blocks. Enables on site use of IP PABX, intranet and email for SMBs on
XDSL/Fibre.

o   zone_tool command line administrative tool on master servers

o   IPSEC secured communications between each of DR master replicas and slaves

o   Modular design. For example, Racoon IPSEC can be replaced if needed.

o   Multiple Slave DNS server software implementations. NL Netlabs nsd3
can be used as a slave server once backend code is completed, and a
simple configuration monitoring/HUP daemon implemented to run on each
slave.

o   slave server/Server Groups (SG) support. Live migration of zones.

o   Private SGs for internal zones.

o   Retention of deleted zones in database for aged auto-deletion later.

o   Multiple Zone Instances per Zone. Roll forward and roll back
changes. Again old ZIs aged for auto deletion above a threshold number.

o   Templates used for generating name server configuration includes -
master, replicas and slaves.

o   Rsync to distribute name server configuration to servers.

o   Central distribution of name server configuration segments.

o   Hot standby master replica for DR purposes with manually controlled
fail over. Includes automatic replica/slave server reconfiguration.

o   WSGI JSON RPC over HTTPS API for mulitple front ends

o   Security tags to control what front ends can see

o   Zone reference metadata to tag the zone with the owner/customer
entity ID. Set by DMI when a zone is created. Tag out of table in DB via
foreign key for easy reference renaming.

o   zone_tool has built in pager support and editor support via standard
shell environment variables.

o   zone_tool has a configurable restricted shell mode for Help Desk use

o   RR Groups and RR comments supported in DB for use in text editor and
in Web Admin DMI (DNS Management Interface)

o   zone_tool has colourised diff support to display changes between
different ZIs for a zone

o   Vim can be used as zone tool editor, giving DNS colourised Zone file
syntax high lighting.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140306075515.5154.49732.report...@sid-dev.internal.anathoth.net

Re: Bits from the Security Team

[Yves-Alexis Perez]

On Thu, Mar 06, 2014 at 07:51:28AM +0800, Paul Wise wrote:
> On Thu, Mar 6, 2014 at 3:03 AM, Moritz Muehlenhoff wrote:
> 
> > * We're planning to request for hidepid to be enabled by default (to 1).
> >   This will squash an entire class of information leaks. If you have any
> >   comments or objections, please get in touch with us.
> 
> Apparently this breaks suspend with systemd and maybe causes some
> issues with login and other things under systemd:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1043134
> http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html
> http://lists.freedesktop.org/archives/systemd-devel/2012-October/006860.html

I do use systemd and hidepid=2 and it seems to work just fine here
(please keep me on CC:, I'm not subscribed to -devel anymore).

From the bug report, I'm quite unsure it's actually related to hidpid=2
and not just to the lack of systemd/logind support in current Xfce
stack.

Regards,
-- 
Yves-Alexis Perez
Debian security team


signature.asc
Description: Digital signature

Re: Bits from the Security Team

[Paul Wise]

On Thu, Mar 6, 2014 at 12:33 PM, Matthias Klose wrote:

> This should not be enabled in the distro itself, and if, then not before it 
> can
> be enabled upstream.  From my point of view it was a mistake to enable it this
> way before getting this upstream.  However it is a lot of work to get the
> compiler to build itself with these flags and the testsuite produce the same
> results as without these.  In the past neither the Ubuntu security team nor 
> the
> Google ChromeOS team had time and resources to bring these patches upstream.

So, probably too much work for a GSoC project? If not would you mentor
such a project?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Bits from the Security Team

[Matthias Klose]

Am 06.03.2014 02:00, schrieb Paul Wise:
>> * The distribution hardening using dpkg-buildflags is coming along
>>   nicely.
> 
> Unfortunately this doesn't apply to binaries compiled outside of the
> package building system. It would be great if we could adopt the
> Ubuntu approach of just enabling the flags in GCC itself. Even better
> would be to get GCC upstream to finally enable them by default.

This should not be enabled in the distro itself, and if, then not before it can
be enabled upstream.  From my point of view it was a mistake to enable it this
way before getting this upstream.  However it is a lot of work to get the
compiler to build itself with these flags and the testsuite produce the same
results as without these.  In the past neither the Ubuntu security team nor the
Google ChromeOS team had time and resources to bring these patches upstream.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5317faa6.6090...@debian.org

Bug#740904: ITP: glamour -- beautiful 2D game with princesses for young girls

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz 

* Package name: glamour
  Version : 1.0.0
  Upstream Author : Nelson do Vale 
* URL : https://launchpad.net/glamour
* License : Code/Art: Public Domain. Music: DFSG-Free
  Programming Lang: Python
  Description : beautiful 2D game with princesses for young girls

In this beautiful strategy game targeted to girls age 8 to 12, each
participant will take control of a princess from a fairy tale. You
must walk through the kingdom collecting shoes, dresses and makeup
to use at the balls, but must be careful: the fashion is always changing.

You play Maddeline, a young girl on her sweet sixteen, who will walk the
whole town looking for the perfect outfit. You will need to avoid getting
you look ruined by the dirty dogs and the bad language of the Viking man.
Watch out not to get late. Avoid playing with the butterflies.

With a lot of strategy, a bit of luck and the right look, you'll be
glamorous at the ball. And maybe even get the heart of the charming
prince.

The game has some very nice graphics and music. It was made after a board
game with the same name.


The package will be maintained collaboratively inside the Games Team


Homepage: http://ocastudios.com/gold/glamour
See also: http://ocastudios.com/videogame/glamour
And finally: http://www.pygame.org/project-Glamour-2859-.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140306014847.14489.23699.reportbug@tabiti.olimpo

Re: Bits from the Security Team

[Craig Small]

On Thu, Mar 06, 2014 at 12:54:00AM +0100, Vincent Danjean wrote:
>   I'm not sure I will let this setup (hidepid=1) on my computers. My
> current POV (that can change) is that I prefer to be able to do the
> maximum of thing as a normal user (top, ps, read log (I'm in the
> adm group), ...) ans switch to root when I really need to do some
> modifications.
You apparently can have a "special" group that can see everything.
That might be worthwhile for a default.

It makes things like pstree look odd, so I'll be expecting some new bug
reports.

Someone might like to fix mount(8) too, especially the bit about procfs
if this is the new default.

 - Craig
-- 
Craig Small (@smallsees)   http://enc.com.au/   csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140306012106.ga30...@enc.com.au

Re: Bits from the Security Team

[Russ Allbery]

Paul Wise  writes:

> Perhaps we could encourage those submitting security bugs to
> X-Debbugs-CC the oss-sec list?

I don't think the list would really appreciate that.  Most of the CVE
requests it currently gets have been vetted by either a developer of the
software or by the security team of a distribution, and right now the
signal-to-noise ratio is very high.  I think we want to at least
peer-review the bug before we send it to oss-sec to make sure that we have
good-quality requests.

We also don't want to do something that would cause the whole bug
discussion to get copied to the list.  The list maintainers aren't
particularly happy when that happens and the discussion drifts away from
the specific security issue.

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


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

Re: Bits from the Security Team

[Paul Wise]

A lot of this is really great news, thanks for your work!

On Thu, Mar 6, 2014 at 3:03 AM, Moritz Muehlenhoff wrote:

> * In some cases source packages get renamed, These
>   renames currently need to be tracked manually. We're planning to
>   automate these. If anyone wants to help and implement it, please see
>   #738172

The debbugs maintainers were going to implement something like this
and Don already has some code apparently so it would be a good idea to
co-ordinate there.

> * We've discussed whether older release information should be kept in
>   the database.

This might be useful for folks still using EOL releases.

> * debsecan is a tool which is closely related to the Security Tracker:

I've 3 patches pending for debsecan so I'd definitely appreciate a
move to collab-maint.

> * There are quite some vulnerabilities which are addressed in Debian,
>   but for which no CVE identifier has been assigned.

Perhaps we could encourage those submitting security bugs to
X-Debbugs-CC the oss-sec list?

Reading LWN I sometimes note the same issue happens for other
distributions. Does the security team monitor the advisory
announcements of upstreams and other distributions and auto-correlate
those with CVEs?

> * We're currently using Subversion. We discussed changing to git, but
>   git doesn't offer significant benefit for our purpose so we decided
>   to stick with it.

>From when alioth was having repository issues, it appears having the
full history locally is useful so git would still be a net win. Also
is the SHA-1 hash chain not useful?

> * In order to avoid bottlenecks and to open up the security process
>   further we're planning to allow maintainers which are not part of
>   the security team to release security updates on their own

The backports archive has a whitelist mechanism, would that be useful?

> * We're tentatively aiming for another Security Team meeting at the
>   beginning of 2015. At that time Jessie will be in freeze which is a
>   good opportunity to plan for jessie/jessie+1.

>From memory some folks not in the security team who wanted to come
missed the last meeting. It would be great to get more people at the
next one.

> * In some cases the scope of security support needs to be limited (e.g
>   webkit-based browsers in Wheezy) and sometimes packages need to
>   end-of-lifed before the security support time frame ends.

A mechanism for this already exists/existed, some links:

https://lists.alioth.debian.org/pipermail/debtags-devel/2008-June/001795.html
https://bugs.debian.org/436161
http://anonscm.debian.org/viewvc/debtags/vocabulary/trunk/security-team?view=markup

> * Our documentation is currently spread across (too) many
>   places. We're planning to create a one-stop site
>   http://security-team.debian.org which links all information wrt to
>   working/contributing on security

Any reason not to use the wiki?

https://wiki.debian.org/Teams/Security

> * The distribution hardening using dpkg-buildflags is coming along
>   nicely.

Unfortunately this doesn't apply to binaries compiled outside of the
package building system. It would be great if we could adopt the
Ubuntu approach of just enabling the flags in GCC itself. Even better
would be to get GCC upstream to finally enable them by default.

> * Since Wheezy the Linux kernel features a security mechanism which
>   nullifies many symlink attacks  kfreebsd (currently a
>   technology preview) and Hurd (currently not a release arch) don't
>   implement this security feature. We welcome feedback from the
>   porters whether similar protections exist or whether they're
>   feasible within the jessie release time frame.

I expect it would be a good idea to directly consult the porting lists
for these ports, not all porters may have read the full mail.

> * At the moment it seems likely that an extended security support
>   timespan for squeeze is possible.
>   The rough draft is that updates will be delivered via a separate
>   suite (e.g. squeeze-lts)

Why not just use the existing suite for this?

Other things:

The information at www.d.o/security could use some updates.

The Ubuntu security folks have a tool called ubuntu-security-tools
that they use for auditing new packages coming in and packages where
flaws are discovered. I expect it would be a lot of work to do that
for Debian but it might be worth it.

git clone bzr::lp:ubuntu-security-tools

Is there much collaboration/synergy with the Ubuntu security team or
those of any other derivatives?

Will security team members be at DebConf14?

Is the team filtering debian-devel-changes and looking for words like
security, overflow, attack etc? This might turn up some things that
don't have CVEs but should.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Bits from the Security Team

[Vincent Danjean]

On 05/03/2014 22:33, Jakub Wilk wrote:
> * Guido Günther , 2014-03-05, 20:54:
>> I looked at the docs and as I read them this would affect uid 0 as well.
> 
> Luckily this is not the case. :) root can see other users' /proc
> entries just fine. Perhaps the documentation should be improved.

  So, it means that most of live supervision I was doing from time to
time as a 'normal' user will need to be done as root (top,
ps axf, ...)
  I'm not sure I will let this setup (hidepid=1) on my computers. My
current POV (that can change) is that I prefer to be able to do the
maximum of thing as a normal user (top, ps, read log (I'm in the
adm group), ...) ans switch to root when I really need to do some
modifications.

  Regards,
Vincent



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5317b918.10...@ens-lyon.org

Re: Bits from the Security Team

[Paul Wise]

On Thu, Mar 6, 2014 at 3:03 AM, Moritz Muehlenhoff wrote:

> * We're planning to request for hidepid to be enabled by default (to 1).
>   This will squash an entire class of information leaks. If you have any
>   comments or objections, please get in touch with us.

Apparently this breaks suspend with systemd and maybe causes some
issues with login and other things under systemd:

https://bugzilla.redhat.com/show_bug.cgi?id=1043134
http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html
http://lists.freedesktop.org/archives/systemd-devel/2012-October/006860.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6EbTYiZYJXaVkJtQm=ru3iDN6O6+VWi4GXZ-1tqs9m=u...@mail.gmail.com

Re: Bits from the Security Team

[Jakub Wilk]

* Guido Günther , 2014-03-05, 20:54:
* We're planning to request for hidepid to be enabled by default (to 
1). This will squash an entire class of information leaks. If you have 
any comments or objections, please get in touch with us.


For the lazy, this is documentation for hidepid:

hidepid=0 means classic mode - everybody may access all /proc// 
directories (default).


hidepid=1 means users may not access any /proc// directories but 
their own. Sensitive files like cmdline, sched*, status are now 
protected against other users. This makes it impossible to learn whether 
any user runs specific program (given the program doesn't reveal itself 
by its behaviour). As an additional bonus, as /proc//cmdline is 
unaccessible for other users, poorly written programs passing sensitive 
information via program arguments are now protected against local 
eavesdroppers.


hidepid=2 means hidepid=1 plus all /proc// will be fully invisible 
to other users. It doesn't mean that it hides a fact whether a process 
with a specific pid value exists (it can be learned by other means, e.g. 
by "kill -0 $PID"), but it hides process' uid and gid, which may be 
learned by stat()'ing /proc// otherwise. It greatly complicates an 
intruder's task of gathering information about running processes, 
whether some daemon runs with elevated privileges, whether other user 
runs some sensitive program, whether other users run any program at all, 
etc.


I looked at the docs and as I read them this would affect uid 0 as 
well.


Luckily this is not the case. :) root can see other users' /proc entries 
just fine. Perhaps the documentation should be improved.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140305213323.ga9...@jwilk.net

Bug#740886: ITP: libposix-strftime-compiler-perl -- GNU C library compatible strftime for loggers and servers

[Florian Schlichting]

Package: wnpp
Severity: wishlist
Owner: Florian Schlichting 

* Package name: libposix-strftime-compiler-perl
  Version : 0.31
  Upstream Author : Masahiro Nagano 
* URL : https://metacpan.org/release/POSIX-strftime-Compiler
* License : GPL-1+, Artistic
  Programming Lang: Perl
  Description : GNU C library compatible strftime for loggers and servers

POSIX::strftime::Compiler provides a GNU C library compatible
strftime(3), which is not affected by the system locale. This is useful
when you want to write loggers, servers and portable applications that
generate the same result strings on any locale.  Technically,
POSIX::strftime::Compiler wraps POSIX::strftime and converts some format
characters to perl code.

libposix-strftime-compiler-perl is a new dependency of
libapache-logformat-compiler-perl and will be maintained by pkg-perl


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140305201134.20403.72493.reportbug@thinkpad

Re: Bits from the Security Team

[Guido Günther]

Hi,
the work of the security team is very, very much appreciated!

On Wed, Mar 05, 2014 at 08:03:01PM +0100, Moritz Muehlenhoff wrote:
> * We're planning to request for hidepid to be enabled by default (to 1).
>   This will squash an entire class of information leaks. If you have any
>   comments or objections, please get in touch with us.

I looked at the docs and as I read them this would affect uid 0 as well.
In this case tools like checkrestart and whatmaps wouldn't be able to
detect mapped libraries anymore actually preventing security updates for
running processes. Maybe excempting uid 0 would be good.
Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140305195409.gb23...@bogon.m.sigxcpu.org

Re: RSA vs ECDSA (Was: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!)

[Kurt Roeckx]

On Wed, Mar 05, 2014 at 08:29:37AM +0100, Ondrej Surý wrote:
> On Tue, Mar 4, 2014, at 21:33, Gunnar Wolf wrote:
> > Ondrej Surý dijo [Tue, Mar 04, 2014 at 08:10:47PM +0100]:
> > > On Mon, Mar 3, 2014, at 19:13, Gunnar Wolf wrote:
> > > > As keyring maintainers, we no longer consider 1024D keys to be
> > > > trustable. We are not yet mass-removing them, because we don't want to
> > > > hamper the project's work, but we definitively will start being more
> > > > aggressively deprecating their use. 1024D keys should be seen as
> > > > brute-force vulnerable nowadays. Please do migrate away from them into
> > > > stronger keys (4096R recommended) as soon as possible.
> > > 
> > > I am not sure what's the timeframe for GnuPG 2.1.0[1] release, but would
> > > it be possible to skip the RSA and go directly for ECDSA, before we
> > > start deprecating DSA? Or at least have an option to do so? (Well,
> > > unless GnuPG 2.1 release is too much far in the future.)
> > 
> > Umh, I feel I have to answer this message, but I clearly don't have
> > enough information to do so in an authoritative way¹. AIUI, ECDSA has
> > not been shown to be *stronger* than RSA -- RSA works based on modulus
> > operations, ECDSA on curve crypto. ECDSA keys can be smaller and
> > achieve (again, AIUI) the same level of security. But nothing so far
> > shows that RSA will be broken before or after ECDSA.
> > 
> > Barring somebody pointing me to the right place to read, my take would
> > be that we should accept both RSA and ECDSA keys
> 
> Yes. I didn't suggest that we drop RSA.
> 
> > (of what minimum size/strength?).
> 
> These might provide a guidance (even for RSA key lengths).
> 
> http://www.keylength.com/en/compare/#Biblio4
> http://csrc.nist.gov/groups/ST/toolkit/key_management.html
> 
> and
> 
> http://csrc.nist.gov/publications/nistpubs/800-78-3/sp800-78-3.pdf
> 
> NIST seems to recommend at least 2048 bits for RSA and Curve P-256 for
> ECDSA

You might want to take a look at http://safecurves.cr.yp.to/
before using the P-curves.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140305180926.ga3...@roeckx.be

Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!

[Xavier Roche]

Le 05/03/2014 15:05, Jeremy T. Bouse a écrit :
> I would tend to side more with Odyx here in that the keys are still
> considered trustworthy enough to be in the keyring but we're encouraging
> moving to stronger keys and no longer accepting these keys to be
> included.

Yes, this was my thoughts, too.

Or, to rephrase it: 1024D keys will "soon" be breakable (let's say in
few years), but at this present time, they are still trustworthy enough
to allow transition.

It doesn't mean that eventually, they'll be considered untrustworthy, later.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53176321.50...@httrack.com

Bug#740865: ITP: python-srs -- Python SRS (Sender Rewriting Scheme) library

[Sandro Knauß]

Package: wnpp
Severity: wishlist
Owner: "Sandro Knauß" 

* Package name: python-srs
  Version : 0.30.11
  Upstream Author : Stuart Gathman 
* URL : http://bmsi.com/python/pysrs.html
* License : Python License (CNRI Python License)
  Programming Lang: Python
  Description : Python SRS (Sender Rewriting Scheme) library

 As SPF is implemented, MTAs that check SPF must account for any forwarders.
 One way to handle forwarding is to have the forwarding MTA rewrite envfrom to a
 domain they are authorized to use.
 .
 More information about SRS:  http://spf.pobox.com/srs.html

This package is part of the python-milter project. I intend to maintain it 
under the Debian Python
Maintainers umbrella. Scott K agreed to sponser me with this packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140305171740.19541.81822.reportbug@tabin.local

Bug#740858: ITP: madgwick-ahrs -- Madgwick and Mahony attitude and heading reference (AHRS) algorithms

[Klee Dienes]

Package: wnpp
Severity: wishlist
Owner: Klee Dienes 

* Package name: madgwick-ahrs
  Version : 0.0.20120219-1
  Upstream Author : Sebastian Madgwick
* URL : http://www.x-io.co.uk/open-source-imu-and-ahrs-algorithms
* License : CC-SA 3.0
  Programming Lang: C
  Description : Madgwick and Mahony attitude and heading reference (AHRS) 
algorithms

In 2009 Sebastian Madgwick developed an IMU and AHRS sensor fusion
algorithm as part of his Ph.D research at the University of
Bristol. This library also includes Madgwick’s implementation of
Robert Mayhony’s ‘DCM filter‘ in quaternion form.

---

This package is used by the psmoveapi package for orientation
tracking.  It's also suitable for use as a general-purpose AHRS
algorithm.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140305162726.6722.61883.report...@router.dienesfamily.org

Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!

[Jeremy T. Bouse]

On 05.03.2014 04:01, Didier 'OdyX' Raboud wrote:

Le mercredi, 5 mars 2014, 10.47:07 Paul Wise a écrit :

On Wed, Mar 5, 2014 at 1:55 AM, Xavier Roche wrote:
> I have a rather silly question: would a mail (signed with this 
key)

> request to the DDs who already signed the initial key (and checked
> the identity) to sign the replacement key considered unreasonable 
?

Considering that the initial keys are now considered weak, I expect
that it would be reasonable for people to not trust a key transition
statement where the only available trust anchor is the old weak key.


Well, the project currently considers these old keys to be 
trustworthy
enough to let the people who control them to upload any packages on 
the

archive (modulo these keys are in the uploading keyring).

If we trust that the people behind the keys haven't changed, we 
should
let them use easy ways to stronger keys. On the other hand, if we 
think

the keys have been compromised, then we should really drop the upload
rights!

Cheers,
OdyX


I would tend to side more with Odyx here in that the keys are still 
considered trustworthy enough to be in the keyring but we're encouraging 
moving to stronger keys and no longer accepting these keys to be 
included. The subject of compromise is a totally different situation 
than this and would obviously need to be handled differently as you 
should no longer trust the key entirely and should be removed.


I started the move to the high bit RSA key because of deciding to make 
the move to using the OpenPGP smartcard which only supported RSA and not 
DSA. This was not because I have any reason to believe my key was 
compromised or that I had lost the private key data. Given the lengths I 
go to verify identity, control of private key data and the email 
addresses listed in the UID of the key, I might consider an encrypted 
challenge requesting signing a new replacement key provided the 
assurance that the original key had not been compromised and the keys 
were cross-signed. Though it is something I would most likely take on a 
case by case basis.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/b5138e433b5218bb143b9cfa191db...@undergrid.net

Bug#740822: ITP: colpack -- Graph vertex coloring library

[Barak A. Pearlmutter]

Package: wnpp
Severity: wishlist
Owner: "Barak A. Pearlmutter" 

* Package name: colpack
  Version : 1.0.9
  Upstream Author : Alex Pothen 
* URL : http://www.cscapes.org/coloringpage/
* License : LGPL-3+
  Programming Lang: C++
  Description : Specialized graph vertex coloring library

ColPack is a package comprising of implementation of algorithms for
specialized vertex coloring problems that arise in sparse derivative
computation.  It is written in an object-oriented fashion heavily
using the Standard Template Library (STL).  It is designed to be
simple, modular, extenable and efficient.  Its primary application
has been for use in automatic differentiation.

It is already packaged in Fedora.

The adolc library package can optionally use it, and my reason for
wanting to package colpack is to allow me to enable that option in the
debian adolc package.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140305110417.9259.10354.reportbug@port-kdr.hamilton.local

Re: Adiscon LogAnalyzer? rsyslog + mongodb?

[Daniel Pocock]

On 05/03/14 09:09, Florian Ernst wrote:
> Hello all,
>
> On Tue, Mar 04, 2014 at 03:49:25PM +0100, Daniel Pocock wrote:
>> The rsyslog mongodb output module and the PHP mongodb modules are now in
>> wheezy-backports.  This would appear to be sufficient to do something like:
>>
>> rsyslog => mongodb => loganalyzer
>>
>> Has anybody else tried that or does anybody have any comments on it (or
>> recommended alternatives)?
> That actually did work for a time, but something broke starting with
> rsyslog 7.4.0-1. Since then the format of the data dumped into mongodb
> doesn't match what tools like loganalyzer expect, cf. #721277 / #728827.
> As I was merely experimenting with it I didn't follow up any further.

Some of this looks like documentation bugs and/or problems with the
default config rather than mongodb integration itself

LogAnalyzer and rsyslog are from the same upstream too, so I would be
surprised if they would not have them working together

I had a look at the Git history for the ommongodb, does anything stand
out here?

https://github.com/rsyslog/rsyslog/commits/master/plugins/ommongodb

You state the problem started with 7.4.0-1 - could you comment on the
previous set of versions that you had working (both rsyslog and
LogAnalyzer versions)?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5316f75c.3020...@pocock.pro

Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!

[Thibaut Paumard]

Le 05/03/2014 10:01, Didier 'OdyX' Raboud a écrit :
> Le mercredi, 5 mars 2014, 10.47:07 Paul Wise a écrit :
>> On Wed, Mar 5, 2014 at 1:55 AM, Xavier Roche wrote:
>>> I have a rather silly question: would a mail (signed with this key)
>>> request to the DDs who already signed the initial key (and checked
>>> the identity) to sign the replacement key considered unreasonable ?
>> Considering that the initial keys are now considered weak, I expect
>> that it would be reasonable for people to not trust a key transition
>> statement where the only available trust anchor is the old weak key.
> 
> Well, the project currently considers these old keys to be trustworthy 
> enough to let the people who control them to upload any packages on the 
> archive (modulo these keys are in the uploading keyring).
> 
> If we trust that the people behind the keys haven't changed, we should 
> let them use easy ways to stronger keys. On the other hand, if we think 
> the keys have been compromised, then we should really drop the upload 
> rights!
> 

Hi,

On the same line of thought, couldn't we manage something with
videoconferencing tools, at least for key renewal? Just to check that
the person I'm signing the new key resembles the one I met a couple of
years ago. I'm quite sure I would still be able to identify most of the
DDs whose key I signed.

Kind regards, Thibaut.




signature.asc
Description: OpenPGP digital signature

Re: Adiscon LogAnalyzer? rsyslog + mongodb?

[Daniel Pocock]

On 04/03/14 18:04, Nicolas Dandrimont wrote:
> * Daniel Pocock  [2014-03-04 15:49:25 +0100]:
>
>> I didn't see any existing package of LogAnalyzer from Adiscon, the
>> people who make rsyslog - is there any specific reason for not packaging
>> it or it is just not something anybody needed yet?  It is GPL:
>>
>> http://loganalyzer.adiscon.com/
>>
>> http://download.adiscon.com/loganalyzer/loganalyzer-3.6.5.tar.gz
>>
>> The rsyslog mongodb output module and the PHP mongodb modules are now in
>> wheezy-backports.  This would appear to be sufficient to do something like:
>>
>> rsyslog => mongodb => loganalyzer
>>
>> Has anybody else tried that or does anybody have any comments on it (or
>> recommended alternatives)?
>>
>> http://loganalyzer.adiscon.com/articles/using-mongodb-with-rsyslog-and-loganalyzer/
> Hi,
>
> At work, I have been investigating the ElasticSearch + Logstash[1] + Kibana[2]
> combo, which has been pretty solid in my tests so far (feeding it 10GB or so 
> of
> firewall logs a day, yes, that thing is noisy).
>
> There is no Debian packaging of that stack yet (the RFP of logstash is at 
> [3]),
> and I haven't investigated the upstream-provided repositories either (AIUI,
> they appeared after my tests, so I ran the stuff from the "flatjar" bundle, 
> ick).

This is obviously the more advanced and feature-rich solution (and I
notice they include syslog in their long list of connectivity options):

http://cookbook.logstash.net/recipes/rsyslog-agent/
  "The logstash agent, when run from java, can incur significant
overhead. The minimum memory footprint I have been able to achieve is
about 100mb. On tiny virtual machines, this may not be acceptable, so
you need an alternative."  (an alternative that every Debian system
contains already being a good choice)

I had a look at the distribution artifact (the flat JAR), it is a mix of
Java and Ruby, including various dependencies.  As everything is merged
into a single JAR it wasn't immediately obvious what the dependencies
are and which ones are essential but I'm guessing from the long list of
connector options that some are optional and packaging may involve
allowing people to mix and match.

For my own use cases, a Debian package isn't always a requirement and
the features this offers appear more compelling.

For some people (and some of my own use cases), LogAnalyzer is probably
enough as well and if a trivial integration with mongodb is going to be
possible in jessie, I felt it would be a nice thing for Debian.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5316f403.5080...@pocock.pro

Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!

[Didier 'OdyX' Raboud]

Le mercredi, 5 mars 2014, 10.47:07 Paul Wise a écrit :
> On Wed, Mar 5, 2014 at 1:55 AM, Xavier Roche wrote:
> > I have a rather silly question: would a mail (signed with this key)
> > request to the DDs who already signed the initial key (and checked
> > the identity) to sign the replacement key considered unreasonable ?
> Considering that the initial keys are now considered weak, I expect
> that it would be reasonable for people to not trust a key transition
> statement where the only available trust anchor is the old weak key.

Well, the project currently considers these old keys to be trustworthy 
enough to let the people who control them to upload any packages on the 
archive (modulo these keys are in the uploading keyring).

If we trust that the people behind the keys haven't changed, we should 
let them use easy ways to stronger keys. On the other hand, if we think 
the keys have been compromised, then we should really drop the upload 
rights!

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1698122.Pbb9aiM70E@gyllingar

Re: Adiscon LogAnalyzer? rsyslog + mongodb?

[Florian Ernst]

Hello all,

On Tue, Mar 04, 2014 at 03:49:25PM +0100, Daniel Pocock wrote:
> The rsyslog mongodb output module and the PHP mongodb modules are now in
> wheezy-backports.  This would appear to be sufficient to do something like:
> 
> rsyslog => mongodb => loganalyzer
> 
> Has anybody else tried that or does anybody have any comments on it (or
> recommended alternatives)?

That actually did work for a time, but something broke starting with
rsyslog 7.4.0-1. Since then the format of the data dumped into mongodb
doesn't match what tools like loganalyzer expect, cf. #721277 / #728827.
As I was merely experimenting with it I didn't follow up any further.

We ended up using hadoop for some log analysis, but that's quite a
different framework for such a task and as such requires a copious
amount of study ... YMMV.

Cheers,
Flo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140305080931.ga7...@fernst.no-ip.org