Re: NRSS has been deprecated [#696302]

2016-10-29 Thread Adam Borowski 
On Fri, Oct 21, 2016 at 02:24:20PM +0800, Paul Wise wrote:
> On Fri, Oct 21, 2016 at 1:34 PM, Adam Borowski wrote:
> 
> > we should have some way to query if anybody would object to a package's 
> > removal?
> 
> We definitely need better ways to connect with package users, but it
> might be hard to do that in a privacy preserving way. Perhaps
> something similar to popcon, but in reverse could help there. A
> web/onion service where users can download details of packages that
> might need user attention, along with an opt-in client that
> periodically downloads the current list and matches it against user
> preferences and installed packages.

Here's an idea: what about a new type of WNPP bug, "Intent-To-Remove"?
An user interested in future releases is usually a contributor of sorts,
thus often has "devscripts" installed.  We already have rc-alert and
wnpp-alert, adding a cronjob that checks for new ITRs and mails you (once!)
if there's one that matches one of your installed package would require no
server-side changes and only a trivial copy client-side.  It'd obviously
need to be put into a package on its own (as "devscripts" shouldn't access
network by default), but "if [ -x /usr/bin/torify ]; then torify itr-alert;
else itr-alert; fi" is not exactly rocket surgery.

A maintainer would then file "ITR: dasher" and wait for responses before
requesting RM.

It'd be especially great for QA.  I have the following script:
.--[ qarc ]
#!/bin/sh

rc-alert -dU \
  `wget -qO- http://www.debian.org/devel/wnpp/orphaned|
  sed -ne 's/.*\([^:<]*\)[: 
]*\([^<]*\)<\/a>.*/O \1 \2 -- \3/; T d; p; : d'|
  cut -d' ' -f 3`
`
and whenever I stare at its output, 95% entries make me think "would anyone
give a damn about this?", shrug and look away.

Once stretch is released, we'd file thousands of ITRs, listen to the
crickets for a bit, then greatly decruft the archive!  Without, there's no
knowing if we'd harm someone (although if popcon is 4 or so, that's probably
telling enough).


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: Bug#842349: ITP: node-glob-base -- Returns an object with the (non-glob) base path and the actual pattern

2016-10-29 Thread Paul Wise 
On Sun, Oct 30, 2016 at 12:05 PM, Adam Borowski wrote:

> That database looks like something easy to check, and since most if not all
> Debian node.js packages use naming consistent with npm, it could be
> automated.  (Please tell me it already is.)

It is not automated. Every few months I find a bit of time to go
through the recent nodesecurity posts and file bugs or ping
maintainers but I doubt I'll be doing that again soon. Except for CVEs
from MITRE, all of the data collection for the Debian security tracker
is manual at this point (and a significant proportion is done by
carnil). In case anyone wants to help fix that, check out these
initial thoughts:

https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal
https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Bug#842349: ITP: node-glob-base -- Returns an object with the (non-glob) base path and the actual pattern

2016-10-29 Thread Adam Borowski 
On Sat, Oct 29, 2016 at 01:10:43PM +0800, Paul Wise wrote:
> On Sat, Oct 29, 2016 at 12:00 AM, Russ Allbery wrote:
> 
> > such as patching Javascript for security vulnerabilities
> 
> FYI, the Debian security team does not support the NodeJS ecosystem.
> We probably need more folks following Node security issues. Some of
> those are listed here:
> 
> https://nodesecurity.io/advisories

That database looks like something easy to check, and since most if not all
Debian node.js packages use naming consistent with npm, it could be
automated.  (Please tell me it already is.)

>From what I heard they pay little heed to security issues that apply to any
but the newest-and-greatest version so support for stretch when it's 5 years
old will be rather sketchy -- yet some fixes are better than none.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Bug#842523: RFP: doconce -- lightweight documentation markup language

2016-10-29 Thread Ben Finney 
Package: wnpp
Severity: wishlist
Owner: Ben Finney 

* Package name: doconce
  Version : 1.3
  Upstream Author : Hans Petter Langtangen 
* URL : https://hplgit.github.io/doconce/doc/web/index.html
* License : BSD-3-clause
  Programming Lang: Python
  Description : lightweight documentation markup language
DocOnce is a modestly tagged (Markdown-like) markup language
targeting scientific reports, software documentation, books, blog
posts, and slides involving much math and code in the text.
.
From DocOnce source you can generate LaTeX, Sphinx, HTML, IPython
notebooks, Markdown, MediaWiki, and other formats. This means that
you get the most up-to-date publishing technologies for paper,
tablets, and phones.

-- 
 \   己所不欲、勿施于人。 (What is undesirable to you, |
  `\ do not do to others.) |
_o__)—孔夫子 Confucius (551 BCE – 479 BCE) |
Ben Finney 


signature.asc
Description: PGP signature

Re: Autogenerated -dbgsym packages made my package by REJECTed

2016-10-29 Thread Adam Borowski 
On Sat, Oct 29, 2016 at 08:39:48PM -0400, Paul R. Tagliamonte wrote:
> On Oct 29, 2016 7:29 PM, "Ian Jackson" 
> wrote:
> > I've dput'd my upload again.  Hopefully it won't fall foul of some
> > anti-replay measure...
>
> IIRC it will, it stores seen signature hashes

Only the .changes file seems to be remembered, re-sign it and it will be
accepted.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: Autogenerated -dbgsym packages made my package by REJECTed

2016-10-29 Thread Paul R. Tagliamonte 
IIRC it will, it stores seen signature hashes

On Oct 29, 2016 7:29 PM, "Ian Jackson" 
wrote:

> Julien Cristau writes ("Re: Autogenerated -dbgsym packages made my package
> by REJECTed"):
> > Right, fasolo had jessie's lintian.  Upgraded to jessie-backports now,
> > sorry for the inconvenience.
>
> Thanks for the quick response.
>
> I've dput'd my upload again.  Hopefully it won't fall foul of some
> anti-replay measure...
>
> Ian.
>
> --
> Ian JacksonThese opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
>
>

Bug#842519: ITP: libwww-form-urlencoded-xs-perl -- XS implementation of application/x-www-form-urlencoded parser/builder

2016-10-29 Thread gregor herrmann 
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libwww-form-urlencoded-xs-perl
  Version : 0.23
  Upstream Author : Masahiro Nagano 
* URL : https://metacpan.org/release/WWW-Form-UrlEncoded-XS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : XS implementation of application/x-www-form-urlencoded 
parser/builder

WWW::Form::UrlEncoded::XS provides an application/x-www-form-urlencoded
encoding parser and builder that is implemented by XS. This will be used
by WWW::Form::UrlEncoded (libwww-form-urlencoded-perl) transparently.

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

Bug#842518: ITP: libtest2-workflow-perl -- module structuring tests using composable units

2016-10-29 Thread gregor herrmann 
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest2-workflow-perl
  Version : 0.17
  Upstream Author : Chad Granum 
* URL : https://metacpan.org/release/Test2-Workflow
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module structuring tests using composable units

A test workflow is a way of structuring tests using composable units. A well
known example of a test workflow is RSPEC . RSPEC is
implemented using Test2::Workflow in Test2::Tools::Spec along with several
extentions.

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

Re: Autogenerated -dbgsym packages made my package by REJECTed

2016-10-29 Thread Ian Jackson 
Julien Cristau writes ("Re: Autogenerated -dbgsym packages made my package by 
REJECTed"):
> Right, fasolo had jessie's lintian.  Upgraded to jessie-backports now,
> sorry for the inconvenience.

Thanks for the quick response.

I've dput'd my upload again.  Hopefully it won't fall foul of some
anti-replay measure...

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#842516: ITP: libtest2-asyncsubtest-perl -- module for asynchronous subtests

2016-10-29 Thread gregor herrmann 
Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest2-asyncsubtest-perl
  Version : 0.18
  Upstream Author : Chad Granum 
* URL : https://metacpan.org/release/Test2-AsyncSubtest
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for asynchronous subtests

Regular subtests have a limited scope, they start, events are generated, then
they close and send an Test2::Event::Subtest event. This is a problem if you
want the subtest to keep receiving events while other events are also being
generated. Test2::AsyncSubtest implements subtests that stay pen until you
decide to close them.

This is mainly useful for tools that start a subtest in one process or thread
and then spawn children. In many cases it is nice to let the parent process
continue instead of waiting on the children.

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

Re: Autogenerated -dbgsym packages made my package by REJECTed

2016-10-29 Thread Julien Cristau 
On Sat, Oct 29, 2016 at 22:54:57 +0200, Magnus Holmgren wrote:

> lördag 29 oktober 2016 kl. 21:35:14 CEST skrev  Ian Jackson:
> > Debian FTP Masters writes ("xen_4.8.0~rc3-0exp1_multi.changes REJECTED"):
> > > libxenstore3.0-dbgsym: lintian output: 'extended-description-is-empty ',
> > > automatically rejected package. libxen-4.8-dbgsym: lintian output:
> > > 'extended-description-is-empty ', automatically rejected package.
> > > xenstore-utils-dbgsym: lintian output: 'extended-description-is-empty ',
> > > automatically rejected package. xen-utils-4.8-dbgsym: lintian output:
> > > 'extended-description-is-empty ', automatically rejected package.
> > > 
> > > ===
> > > 
> > > Please feel free to respond to this email if you don't understand why
> > > your files were rejected, or if you upload new files which address our
> > > concerns.
> > 
> > These .debs were generated automatically by debhelper.  It is true
> > that they don't have extended descriptions, but I think that's
> > correct.  None of the docs I could find on this new feature [1] seem
> > to cover this aspect.
> 
> I was going to ask the same. Is the new ftp-master server running an old 
> lintian? The changelog of lintian 2.5.31 says "Allow debug packages without 
> an 
> extended description.", and since they're generated automatically by 
> debhelper 
> without entries in debian/control, we are not supposed to be required to add 
> such entries, are we?
> 
Right, fasolo had jessie's lintian.  Upgraded to jessie-backports now,
sorry for the inconvenience.

Cheers,
Julien

Re: Autogenerated -dbgsym packages made my package by REJECTed

2016-10-29 Thread Magnus Holmgren 
lördag 29 oktober 2016 kl. 21:35:14 CEST skrev  Ian Jackson:
> Debian FTP Masters writes ("xen_4.8.0~rc3-0exp1_multi.changes REJECTED"):
> > libxenstore3.0-dbgsym: lintian output: 'extended-description-is-empty ',
> > automatically rejected package. libxen-4.8-dbgsym: lintian output:
> > 'extended-description-is-empty ', automatically rejected package.
> > xenstore-utils-dbgsym: lintian output: 'extended-description-is-empty ',
> > automatically rejected package. xen-utils-4.8-dbgsym: lintian output:
> > 'extended-description-is-empty ', automatically rejected package.
> > 
> > ===
> > 
> > Please feel free to respond to this email if you don't understand why
> > your files were rejected, or if you upload new files which address our
> > concerns.
> 
> These .debs were generated automatically by debhelper.  It is true
> that they don't have extended descriptions, but I think that's
> correct.  None of the docs I could find on this new feature [1] seem
> to cover this aspect.

I was going to ask the same. Is the new ftp-master server running an old 
lintian? The changelog of lintian 2.5.31 says "Allow debug packages without an 
extended description.", and since they're generated automatically by debhelper 
without entries in debian/control, we are not supposed to be required to add 
such entries, are we?

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Autogenerated -dbgsym packages made my package by REJECTed

2016-10-29 Thread Ian Jackson 
Debian FTP Masters writes ("xen_4.8.0~rc3-0exp1_multi.changes REJECTED"):
> libxenstore3.0-dbgsym: lintian output: 'extended-description-is-empty ', 
> automatically rejected package.
> libxen-4.8-dbgsym: lintian output: 'extended-description-is-empty ', 
> automatically rejected package.
> xenstore-utils-dbgsym: lintian output: 'extended-description-is-empty ', 
> automatically rejected package.
> xen-utils-4.8-dbgsym: lintian output: 'extended-description-is-empty ', 
> automatically rejected package.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.

These .debs were generated automatically by debhelper.  It is true
that they don't have extended descriptions, but I think that's
correct.  None of the docs I could find on this new feature [1] seem
to cover this aspect.

I made my upload with `sbuild -A' (and dgit built the source package
and used mergechanges to generate the .changes, which I include below
FYI [2]).

Some of the docs suggest doing a source-only upload but AIUI that
would be rejected because it would be NEW.

Can anyone advise what I'm doing wrong ?

Thanks,
Ian.

[1]
 https://wiki.debian.org/AutomaticDebugPackages
 
https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#_new_dbgsym_package_strech_9_0_and_after
 https://lists.debian.org/debian-devel-announce/2016/01/msg0.html

[2]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 24 Oct 2016 17:31:27 +0100
Source: xen
Binary: libxen-4.8 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common 
xen-utils-4.8 xen-hypervisor-4.8-amd64 xen-system-amd64 
xen-hypervisor-4.8-arm64 xen-system-arm64 xen-hypervisor-4.8-armhf 
xen-system-armhf
Architecture: all amd64 source
Version: 4.8.0~rc3-0exp1
Distribution: experimental
Urgency: high
Maintainer: Debian Xen Team 
Changed-By: Ian Jackson 
Description: 
 libxen-4.8 - Public libs for Xen
 libxen-dev - Public headers and libs for Xen
 libxenstore3.0 - Xenstore communications library for Xen
 xen-hypervisor-4.8-amd64 - Xen Hypervisor on AMD64
 xen-hypervisor-4.8-arm64 - Xen Hypervisor on ARM64
 xen-hypervisor-4.8-armhf - Xen Hypervisor on ARMHF
 xen-system-amd64 - Xen System on AMD64 (meta-package)
 xen-system-arm64 - Xen System on ARM64 (meta-package)
 xen-system-armhf - Xen System on ARMHF (meta-package)
 xen-utils-4.8 - XEN administrative tools
 xen-utils-common - Xen administrative tools - common files
 xenstore-utils - Xenstore command line utilities for Xen
Changes:
 xen (4.8.0~rc3-0exp1) experimental; urgency=high
 .
   * New upstream version, Xen 4.8.0 RC3.
 Fixes many outstanding CVEs.
   * Incorporated many changes from 4.8.0-0ubuntu2
 - libxen-dev is M-A: same
 - Work around grep bug http://bugs.launchpad.net/bugs/1547466
 - debian/xen-hypervisor-4.6.xen.cfg:
   Additional config file to simplify grub configuration.
 - Use new library/abiname scheme.
 - Document what xl and xm are in default.xen
 - Add libvirtd dependency to xendomains init script
 (Thanks to Stefan Bader and others.)
Checksums-Sha1: 
 cb026271b62b1632b2c5ad1c376332be39b8ec7f 2690 xen_4.8.0~rc3-0exp1.dsc
 d8050a2c591c5111368abe479bf25217d178 5533102 xen_4.8.0~rc3.orig.tar.gz
 cc75c3a5eb1f88d05960e88ab5802474418373ad 49836 
xen_4.8.0~rc3-0exp1.debian.tar.xz
 8d667aa9ea04e7699ac46ab351dc3cf96a638423 1607842 
libxen-4.8-dbgsym_4.8.0~rc3-0exp1_amd64.deb
 bbaba67d87c5f9d95d5d5e0b0fa3dd1e37f6c9fd 407812 
libxen-4.8_4.8.0~rc3-0exp1_amd64.deb
 505a21affee1e25413bdde848cd3d678948e6ae1 647340 
libxen-dev_4.8.0~rc3-0exp1_amd64.deb
 260ffb016bdcebd2bf83b800b0af8c7f388fe897 25164 
libxenstore3.0-dbgsym_4.8.0~rc3-0exp1_amd64.deb
 449ef119dbd32e4011140539444d771d6853b510 31304 
libxenstore3.0_4.8.0~rc3-0exp1_amd64.deb
 f10f480e46694354a6434f2026bad1c1b2632940 1887306 
xen-hypervisor-4.8-amd64_4.8.0~rc3-0exp1_amd64.deb
 3b3453eb0889e4da3e745a2134fbc8767ab7ea78 20326 
xen-system-amd64_4.8.0~rc3-0exp1_amd64.deb
 3668df0946ea4058f027666d62b86f8dc1f8b85c 845770 
xen-utils-4.8-dbgsym_4.8.0~rc3-0exp1_amd64.deb
 6adbb032c56357f0e19508a7e84e58bf571020de 413860 
xen-utils-4.8_4.8.0~rc3-0exp1_amd64.deb
 bcbc2f7b2281c6e2062eeda5a7e9735bead34e48 277004 
xen-utils-common_4.8.0~rc3-0exp1_all.deb
 59a4e0977e063c428d3374db0d6c25f777886254 13330 
xenstore-utils-dbgsym_4.8.0~rc3-0exp1_amd64.deb
 53db037fb3613f692251bde6633162a67c769248 26784 
xenstore-utils_4.8.0~rc3-0exp1_amd64.deb
Checksums-Sha256: 
 2a977ba043a6f9e3b549f95e8c87a1f90e3c227a783e654eeb830cc1bc2a03bd 2690 
xen_4.8.0~rc3-0exp1.dsc
 544821a29e7c6082069c3053769c42233460a0c19779c8220a123c186b903940 5533102 
xen_4.8.0~rc3.orig.tar.gz
 99e8dcc188a01a07d7a08567f5ece697549a411fb05ecbe6ad3eabb783c04dd4 49836 
xen_4.8.0~rc3-0exp1.debian.tar.xz
 713944db082fc29948e02d0356bf1e7d79129fa2cd1289c980eec834c8c09a6e 1607842 
libxen-4.8-dbgsym_4.8.0~rc3-0exp1_amd64.deb
 a2a6b7b338ae1fdd93dbfaeb3c37a71ecbb67ec5af2992d21167

Re: openssl transition

2016-10-29 Thread Christian Seiler 
On 10/29/2016 09:27 PM, Michael Meskes wrote:
>> - The parallel use of release 1.0 and 1.1 will not be pursued?
>>
>> - Why is the transition started with 0 (zero) good packages (from
> 552)?
>> ... 
> 
> May I add one more, and actually pretty pressing question? How are we
> supposed to upload "fixed" packages?
> 
> I have two that are said to be removed in, like, 12 days. If I upload
> those to experimental, it will not prevent the auto-removal. Uploading
> to sid will make the packages uninstallable for obvious reasons. And
> then there's the "transition freeze" in 7 days.
> 
> Let's say I'm a bit confused. Could anyone please tell me how this is
> supposed to be handled?

Well, ideally it'll compile with both OpenSSL 1.0.2 and 1.1 and
therefore be binNMU-able. (This has the advantage that such a
patch is much more likely to get accepted by upstream.) In that
case you can upload a version that Closes: #nnn the RC bug.

When I initially packaged open-isns I did have the looming OpenSSL
transition on my mind, so I added a to makes open-isns build
against both 1.0 and 1.0.2 (and also 1.0.1, for backporting to
Jessie) before the very first upload to sid. Once the SSL
transition gets started, the release team will just have to
binNMU the package once openssl 1.1 is uploaded to sid.
(Also, if you ever want to backport stuff to jessie-backports, it
is necessary to still support building against OpenSSL 1.0 even
after the transition. That's not something relevant for all
packages, as not everything is going to be backported, but there
are definitely some packages that will be affected.)

If you're interested in how that can look like:
https://anonscm.debian.org/cgit/pkg-iscsi/open-isns.git/tree/debian/patches/openssl-1.1.patch
The patch is about the same complexity as a (hypothetical) patch
that just makes the software compile against 1.1 whilst dropping
support for 1.0.  Granted, open-isns is not a heavy user of
OpenSSL, so YMMV here.

Regards,
Christian

Re: when should we esmtps our mxes?

2016-10-29 Thread Ivan Shmakov 
> Ben Hutchings  writes:
> On Mon, 2016-10-24 at 15:15 +, Ivan Shmakov wrote:
> Ben Hutchings  writes:

[…]

 >>> Those certificates look as expected.  Since TLS encryption of SMTP
 >>> between servers is opportunistic, there's no particular reason to
 >>> use a widely trusted CA for server certificates.  A MITM can just
 >>> as easily block STARTTLS as substitute their own key.

My point is: the absence of ‘TLS’ in Received: is a cleaner
indication of the possible tampering of the message.  On the
contrary, its presence in the headers and (or) MX logs may turn
to be misleading when the sending side routinely disregards the
absence of a valid signature on the certificate.

The “opportunisticity” of ESMTPS does not seem relevant.

 >> That’s not necessarily any different to the HTTP(S) case.

 >> For instance, when the user first uses ‘example.com’ as the resource
 >> identifier, the Web user agent (usually) issues a GET request to the
 >> said host’s HTTP server in the plain.  At which point the server
 >> responds with a 302 redirect, pointing to the resource proper (say,
 >> https://example.com/.)

 >> That behavior is hardly any less opportunistic, and is prone to the
 >> very same attack, as demonstrated by ‘sslstrip’.

 > Although that's mitigated by HSTS and bookmarking of https: URLs.

It’s been argued that, as all the CAs are trusted equally (if at
all) by the user agent, it makes sense to minimize the number of
CAs trusted by any specific user – so to reduce the “attack
surface” – and, if necessary, rely on “security exceptions”
instead for the HTTPS sites that use X.509 certificates signed
by marginal (with respect to that same specific user) CAs.

Obviously, implementing RFC 6797 “No User Recourse” provision to
the letter makes that impossible.  Now, given that it seems way
easier to disable HSTS support altogether in the user agent than
to patch one up to get some more sensible behavior…

That said, I see no reason there can’t be some STRICTSECURITY
EHLO keyword, analogous in function to the HSTS header.
Of course, so long as non-TLS ESMTP remains functional –
something that, unfortunately, gradually goes away for HTTP.

[…]

PS.  Now, it makes me wonder, since when are we standardizing
applications to give more heed to the whims of the remote’s
administrator than to the application’s own user?  Free software
used to be better than that; or so I recall.

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: openssl transition

2016-10-29 Thread Michael Meskes 
> - The parallel use of release 1.0 and 1.1 will not be pursued?
>
> - Why is the transition started with 0 (zero) good packages (from
552)?
> ... 

May I add one more, and actually pretty pressing question? How are we
supposed to upload "fixed" packages?

I have two that are said to be removed in, like, 12 days. If I upload
those to experimental, it will not prevent the auto-removal. Uploading
to sid will make the packages uninstallable for obvious reasons. And
then there's the "transition freeze" in 7 days.

Let's say I'm a bit confused. Could anyone please tell me how this is
supposed to be handled?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Bug#842493: ITP: elpa-vimish-fold -- fold text in GNU Emacs like in Vim

2016-10-29 Thread Lev Lamberov 
Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: elpa-vimish-fold
  Version : 0.2.2
  Upstream Author : Mark Karpov 
* URL : https://github.com/mrkkrp/vimish-fold
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : fold text in GNU Emacs like in Vim

This is a package for GNU Emacs to perform text folding like in Vim. It has
 the following features:
 .
  * folding of active regions;
  * good visual feedback: it's obvious which part of text is folded;
  * persistence by default: when you close file your folds don't disappear;
  * persistence scales well, you can work on hundreds of files with lots of
folds without adverse effects;
  * it doesn't break indentation or something;
  * folds can be toggled from folded state to unfolded and back very easily;
  * quick navigation between existing folds;
  * you can use mouse to unfold folds (good for beginners and not only for
them);
  * for fans of `avy' package: you can use `avy' to fold text with minimal
number of key strokes!

Bug#842491: ITP: dfcgen-gtk -- Digital Filter Coefficients Generator (DFCGen) GTK+

2016-10-29 Thread Graham Inggs 
Package: wnpp
Severity: wishlist
Owner: Graham Inggs 
X-Debbugs-CC: debian-devel@lists.debian.org, debian-scie...@lists.debian.org

* Package name: dfcgen-gtk
  Version : 0.4
  Upstream Author : Ralf Hoppe 
* URL : http://www.dfcgen.de
* License : GPL-2.0
  Programming Lang: C
  Description: Digital Filter Coefficients Generator (DFCGen) GTK+
 DFCGen, the Digital Filter Coefficients Generator, assists the engineer
 in the design of digital filters. It supports  the engineer in analysis
 and synthesis of linear time-invariant  time-discrete (LTI) systems
 from the theoretical point of view. It performs  generation of
 system transfer function coefficients in the Z-domain,
 based on the type and specific parameters of a chosen system.

I intend maintaining this package within debian-science.

Re: C:O:.N:.G:.R:.A:.T:.S:William tnH5

2016-10-29 Thread William Brooks 
shields,William

On Sep 24, 2016 3:05 PM, "Helmut Grohne"  wrote:
>
> dfgh
> C0NGRATUIATl0N:William
>
> _WaImart_sent_y0u_glft_card_worth_(1000:D0IIars)
>
> __confirm_immediately__
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [t 0 u n 5 u b U ]
> [t 0 0 p t t 0 0 u t ]
>
>

Bug#842470: ITP: node-global-prefix -- Get the npm global path prefix

2016-10-29 Thread Pirate Praveen 
Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-global-prefix
  Version : 0.1.4
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/global-prefix
* License : Expat
  Programming Lang: JavaScript
  Description : Get the npm global path prefix.



signature.asc
Description: OpenPGP digital signature

Bug#842445: ITP: node-to-regex -- Generate a regex from a string or array of strings

2016-10-29 Thread Pirate Praveen 
Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-to-regex
  Version : 3.0.1
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/to-regex
* License : Expat
  Programming Lang: JavaScript
  Description : Generate a regex from a string or array of strings.



signature.asc
Description: OpenPGP digital signature

Bug#842435: ITP: golang-github-microcosm-cc-bluemonday -- bluemonday: a fast golang HTML sanitizer (inspired by the OWASP Java HTML Sanitizer) to scrub user generated content of XSS

2016-10-29 Thread Michael Lustfield 
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield 

* Package name: golang-github-microcosm-cc-bluemonday
  Version : 0.0~git20161012.0.f77f16f-1
  Upstream Author : Microcosm
* URL : https://github.com/microcosm-cc/bluemonday
* License : BSD-3-clause
  Programming Lang: Go
  Description : HTML sanitizer to scrub user generated content of XSS

 Bluemonday takes untrusted user generated content as an input and will
 return HTML that has been sanitised against a whitelist of approved HTML
 elements and attributes so that you can safely include the content in
 your web page.


I'm packaging this library as a dependency of gogs, but this seems to be a
useful and well written library for preventing XSS.

Bug#842434: ITP: bluemonday -- bluemonday: a fast golang HTML sanitizer (inspired by the OWASP Java HTML Sanitizer) to scrub user generated content of XSS

2016-10-29 Thread Michael Lustfield 
Package: wnpp
Severity: wishlist
Owner: Michael Lustfield 

* Package name: bluemonday
  Version : 0.0~git20161012.0.f77f16f-1
  Upstream Author : Microcosm
* URL : https://github.com/microcosm-cc/bluemonday
* License : BSD-3-clause
  Programming Lang: Go
  Description : HTML sanitizer to scrub user generated content of XSS

 Bluemonday takes untrusted user generated content as an input, and will
 return HTML that has been sanitised against a whitelist of approved HTML
 elements and attributes so that you can safely include the content in
 your web page.


I'm packaging this library as a dependency of gogs, but this seems to be a
useful and well written library for preventing XSS.