Re: Potentially insecure Perl scripts

[Ansgar]

Russ Allbery writes:
> Ben Hutchings writes:
>> People have said this about ASLR, protected symlinks, and many other
>> kinds of security hardening changes.  We made them anyway and took the
>> temporary pain for a long-term security gain.
>
> Well, Perl has a deprecation mechanism with warnings and so forth,
> although I don't think Perl has ever actively broken a feature outside of
> "use " with a later version, except for features marked as
> experimental.  But I suppose it's possible.

'.' was eventually removed from @INC by default.  It also wasn't seen as
a security problem when I reported it as such (or not worth fixing at
the time), but only years later when someone else reported it again.  So
maybe awareness changed a bit.

But "<>" isn't the only problem, there are way too many uses of the
two-argument form of Perl's "open" too...

Ansgar

Fonts hinting to upstream suggestion

[Marek Mosiewicz]

Hello,

I have been trying to have good looking fonts in Debian. What I found
it seems that Firefox ignores dpkg-reconfigure fontconfig-config.

It is not case for Chromium. After playing with native/autohinting
configuration it seems that it is difficult to have all apps looking
good, because some things can use TrueType fonts which looks good with
autohinting and others with native. You can switch gnome fonts
depending on your setting, but you do not know if web page uses
TrueType or font which looks good with native

So the idea. Why not detect if it is TrueType font or native font and
use appropriate hinting method for given font.

Cheers,
   Marek Mosiewicz
   http://marekmosiewicz.pl

Re: Fonts hinting to upstream suggestion

[Jonas Smedegaard]

Hi Marek,

Quoting Marek Mosiewicz (2019-01-24 09:49:35)
> I have been trying to have good looking fonts in Debian. What I found 
> it seems that Firefox ignores dpkg-reconfigure fontconfig-config.
> 
> It is not case for Chromium. After playing with native/autohinting 
> configuration it seems that it is difficult to have all apps looking 
> good, because some things can use TrueType fonts which looks good with 
> autohinting and others with native. You can switch gnome fonts 
> depending on your setting, but you do not know if web page uses 
> TrueType or font which looks good with native
> 
> So the idea. Why not detect if it is TrueType font or native font and 
> use appropriate hinting method for given font.

Sounds like your investigations would be quite helpful to others as 
well: Please consider sharing what you've learned, e.g. on the Debian 
Wiki.

I suspect what need detection here is not if fonts are TrueType or not, 
but whether a font provides custom hinting or not.  And I suspect that 
some fonts provide native hinting but of poor quality, so that 
autohinting is still beneficial for those fonts.

In any case, I believe the way forward is to first try collect knowledge 
on the matter (hence my encouragement above to document on our wiki!) 
and then figure out what to do about it when we know better.

...if if it is just me being stupid here, then great: Point me to the 
already well documented overview somewhere, so I can read up :-D


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Potentially insecure Perl scripts

[Alex Mestiashvili]

On 1/24/19 2:40 AM, Vincent Lefevre wrote:
> On 2019-01-23 17:23:10 +0100, Alex Mestiashvili wrote:
>> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
>>> On 2019-01-23 15:32:00 +, Ian Jackson wrote:
 This is completely mad and IMO the bug is in perl, not in all of the
 millions of perl scripts that used <> thinking it was a sensible thing
 to write.
>>>
>>> I agree that it would be better to drop this "feature" of Perl.
>>> It is probably never used, and probably useless (I would rather
>>> use the features from the shell if I need a pipe).
>>
>> Perl's open is well documented.
> 
> What wasn't clear was not about open, but the fact that <> uses the
> 2-arg open in a raw way. FYI, I learnt Perl in 1994 or early 1995,
> just after Perl 5.000 was released, and at that time, I'm not sure
> that <> was properly documented. More importantly, security was not
> really a consideration (not much except file permissions).
> 
> The fact that the perlsec(1) man page doesn't mention the issue with
> the null filehandle doesn't help either.
> 
> One also has (had) plenty of misleading documentation, starting with
> the perlrun(1) man page:
> 
>-n   causes Perl to assume the following loop around your
> program, which makes it iterate over filename arguments
> somewhat like sed -n or awk:
> 
>   LINE:
> while (<>) {
> ... # your program goes here
> }
> 
> "like sed -n and awk". Really?
> 
> Now, this man page also says:
> 
> Also note that "<>" passes command line arguments to
> "open" in perlfunc, which doesn't necessarily interpret
> them as file names.  See  perlop for possible security
> implications.
> 
> But in 2008, it was still not there. Thus programs written before 2008
> or by developers who started to learn Perl before 2008 can easily be
> affected by this issue.

Thank you for bringing this issue up.
Now, when I grepped through my /usr/bin and found a bunch of old scripts
affected by this I think you are totally right.

But I disagree that a language can be considered insecure, just because
it lets you shoot in the foot.
The first thing I learned when doing CGI coding is to sanitize the
input. That's the root problem in the most cases IMHO.
It's also good to see that perl's documentation gets improved.

> 
> BTW, I've just seen that I already reported a documentation bug in
> the past:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592727
> 
> This was about the behavior, which is not specified, e.g. on
> the argument '>file'.
> 
>> Quoting the perlipc:
>>
>> "it's much more efficient to process the file one line or record at a
>> time because then you don't have to read the whole thing into memory at
>> once."
> 
> Well, with a pipe used from the shell (either with "|" or with
> process substitution) instead of a special Perl syntax, the
> behavior is the same.
> 

This feature is heavily used. Just grepping over my /usr/bin found 31
scripts using this construct and a few of randomly picked up scripts are
affected...

May be lintian's warning for something like "while\s?(\s?<>\s?)" in perl
script explaining people that they should test the scripts is a good
start to eliminate that in Debian?

Re: Potentially insecure Perl scripts

[Adam Borowski]

On Thu, Jan 24, 2019 at 04:41:29AM +, Ben Hutchings wrote:
> On Wed, 2019-01-23 at 09:07 -0800, Russ Allbery wrote:
> > Ian Jackson  writes:
> > > Apparently this has been klnown about for EIGHTEEN YEARS
> > >   https://rt.perl.org/Public/Bug/Display.html?id=2783
> > > and no-one has fixed it or even documented it.
> > 
> > It's been documented for pretty close to eighteen years too.  See
> > perlop(1):
> > 
> >The null filehandle "<>" is special: it can be used to emulate the
> >behavior of sed and awk, and any other Unix filter program that
> >takes a list of filenames, doing the same to each line of input
> >from all of them.  Input from "<>" comes either from standard
> >input, or from each file listed on the command line.
> 
> But this initial description is actively misleading.  It doesn't matter
> that the giant booby-trap is documented several paragraphs further
> down.  Why would a programmer expect that they need to read further
> when they already understand this Unix convention?
> 
> There should be a big flashing WARNING or DEPRECATED right at the top
> of the description.

Even that wouldn't be enough.  This won't help those who learned Perl
before.

I for one did most of my Perl learning ~20 years ago (so just before those
"EIGHTEEN YEARS" you name), and I guess a good deal of Perl users are
similar -- those pesky annoying millenials seem to use exclusively Python,
Perl users being correlated to low-saturation colors of beard.  Yet <>
being broken in such a fundamental way is news to me.  And I don't quite
see any way you could communicate that to me in a way other than a
run-time warning -- you don't re-read docs for basics you believe you
already know well.

> > > I think this is a serious bug in Perl which should be fixed in a
> > > security update.
> > 
> > There is absolutely no way.  So much stuff in Perl depends on this.  You
> > will break all kinds of scripts.  It's been a feature of the language for
> > basically forever.

A run-time warning is annoying but I'd find it warranted.  Just like many
features of C that started printing warnings, you can silence them with
｢no warnings 'foo::bar';｣.

> People have said this about ASLR, protected symlinks, and many other
> kinds of security hardening changes.  We made them anyway and took the
> temporary pain for a long-term security gain.

In this thread, this [mis?]feature of <> has been likened to strcpy().  It's
much worse -- not to the point of gets() but very similar to strncpy() --
something that _looks_ good but is almost never used right.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Re: Potentially insecure Perl scripts

[Guillem Jover]

Hi!

On Wed, 2019-01-23 at 14:05:54 +0100, Vincent Lefevre wrote:
> I've just reported
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269
> 
> against gropdf (also reported upstream to bug-groff), about the use of
> the insecure null filehandle "<>" in Perl, which can lead to arbitrary
> command execution, e.g. when using wildcards.
> 
> I've noticed that some other Perl scripts also use this filehandle and
> might be affected by the same issue.

Part of the problem might also be that perlcritic recommands this in its
InputOutput::ProhibitExplicitStdin policy, you can see the description
with «perlcritic --doc InputOutput::ProhibitExplicitStdin».

For dpkg, for example, I completely disabled that policy as bogus, when
hooking the perlcritic checks in:

  

Thanks,
Guillem

Bug#920350: ITP: pkg-js-autopkgtest -- collection of autopktest scripts for nodejs packages

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: pkg-js-autopkgtest
  Version : 0.1
  Upstream Author : Xavier Guimard 
* URL : https://salsa.debian.org/js-team/pkg-js-autopkgtest
* License : GPL2+
  Programming Lang: Shell
  Description : collection of autopktest scripts for nodejs packages

This package contains test runners to be used with the autopkgtest
infrastructure for nodejs packages.

Packages using the tests with autopkgtests in this package will simply
have to set "Testsuite: autopkgtest-pkg-js" in debian/control and write
upstream test in debian/tests/pkg-js/test. This package provides also a
test.mk file which can be include in debian/rule to avoid writing a
override_dh_auto_test. The same test will be launched.

This package is inspired from pkg-perl-autopkgtest. If accepted, a MR
will be done on autodep8 project to include it.

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-24 11:12:43 +0100, Alex Mestiashvili wrote:
> On 1/24/19 2:40 AM, Vincent Lefevre wrote:
> But I disagree that a language can be considered insecure, just because

Note: just a feature, not the language itself.

> it lets you shoot in the foot.
> The first thing I learned when doing CGI coding is to sanitize the
> input. That's the root problem in the most cases IMHO.

Not really: The point is that if there were real filenames as usual
(possibly with the safe and common exception for "-"), there would
be nothing to sanitize. And as most developers thought these were
real filenames (due to past boggus documentation), they did not try
to sanitize @ARGV. Hence the issue.

> It's also good to see that perl's documentation gets improved.

Yes, but even though it gets improved, it will take much time before
most non-official documentation and examples get fixed too.

> May be lintian's warning for something like "while\s?(\s?<>\s?)" in perl
> script explaining people that they should test the scripts is a good
> start to eliminate that in Debian?

Perhaps, with (as a Perl regexp): (foreach|while)\s*\(\s*<>\s*\)

glilypond, gperl and gpinyin use foreach (perhaps not a good idea,
but that's another matter).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-24 09:46:56 +0100, Ansgar wrote:
> But "<>" isn't the only problem, there are way too many uses of the
> two-argument form of Perl's "open" too...

Perhaps, but at least "open" had correctly been documented since the
beginning, and I quickly learnt to preprend "<" to the filename in
the 1990s (the 3-arg version did not exist at that time, IIRC).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-24 11:18:06 +0100, Adam Borowski wrote:
> On Thu, Jan 24, 2019 at 04:41:29AM +, Ben Hutchings wrote:
> > On Wed, 2019-01-23 at 09:07 -0800, Russ Allbery wrote:
> > > Ian Jackson  writes:
> > > > Apparently this has been klnown about for EIGHTEEN YEARS
> > > >   https://rt.perl.org/Public/Bug/Display.html?id=2783
> > > > and no-one has fixed it or even documented it.
> > > 
> > > It's been documented for pretty close to eighteen years too.  See
> > > perlop(1):
> > > 
> > >The null filehandle "<>" is special: it can be used to emulate the
> > >behavior of sed and awk, and any other Unix filter program that
> > >takes a list of filenames, doing the same to each line of input
> > >from all of them.  Input from "<>" comes either from standard
> > >input, or from each file listed on the command line.
> > 
> > But this initial description is actively misleading.  It doesn't matter
> > that the giant booby-trap is documented several paragraphs further
> > down.  Why would a programmer expect that they need to read further
> > when they already understand this Unix convention?
> > 
> > There should be a big flashing WARNING or DEPRECATED right at the top
> > of the description.
> 
> Even that wouldn't be enough.  This won't help those who learned Perl
> before.

Agreed.

> I for one did most of my Perl learning ~20 years ago (so just before those
> "EIGHTEEN YEARS" you name), and I guess a good deal of Perl users are

Note that the "EIGHTEEN YEARS" was about the above initial bug report.
Concerning the documentation, perlrun(1) was improved only about
10 years ago. This is even more recent.

> similar -- those pesky annoying millenials seem to use exclusively Python,
> Perl users being correlated to low-saturation colors of beard.  Yet <>
> being broken in such a fundamental way is news to me.  And I don't quite
> see any way you could communicate that to me in a way other than a
> run-time warning -- you don't re-read docs for basics you believe you
> already know well.

As for me, even though I knew that <> did something special a few
years ago, I completely forgot it, and only now I noticed that it
could be a security issue in practice.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Ian Jackson]

Guillem Jover writes ("Re: Potentially insecure Perl scripts"):
> Part of the problem might also be that perlcritic recommands this in its
> InputOutput::ProhibitExplicitStdin policy, you can see the description
> with «perlcritic --doc InputOutput::ProhibitExplicitStdin».
> 
> For dpkg, for example, I completely disabled that policy as bogus, when
> hooking the perlcritic checks in:
>   

What this demonstrates (again) is that the Perl community's practice
is inconsistent with the "formal specification" (such as it is) of the
behaviour of <>.

The right answer is to fix the behaviour to be secure and sane by
default.  We can arrange for an environment variable for people who
want to turn the crazy back on.

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.

Re: Potentially insecure Perl scripts

[Ian Jackson]

Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> The right answer is to fix the behaviour to be secure and sane by
> default.  We can arrange for an environment variable for people who
> want to turn the crazy back on.

To the Debian Perl maintainers: if I make a patch to make
  -p -n <>
use the 3-argument form of open (or equivalent), will you apply it ?

To the Debian security team: would you ship it in a security update ?

We already did a much bigger breaking change with @INC and I have to
say that even though some of my own code broke, I thought that was
great.

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#920362: ITP: morsmall -- OCaml libraries for abstract syntax of shell scripts

[Ralf Treinen]

Package: wnpp
Severity: wishlist
Owner: Ralf Treinen 

* Package name: morsmall
  Version : 0.1
  Upstream Author : Yann Régis-Gianas, Nicolas Jeannerod, Ralf Treinen
* URL : https://github.com/colis-anr/morsmall
* License : GPL3
  Programming Lang: OCaml
  Description : OCaml libraries for abstract syntax of shell scripts

 The morsmall library defines a type for abstract syntax trees of
 POSIX shell scripts. It also provides a converter from the concrete
 syntax trees produced by the morbig parser to abstract syntax, and
 a printer from abstract syntax to shell.
 .
 This development library is only useful when you are developing
 OCaml programs that act on shell scripts.

-

This source package will produce one binary package: libmorsmall-ocaml-dev
The package will be maintained in the ocaml-team.

-Ralf.

Re: Potentially insecure Perl scripts

[Mark Fowler]

On Thu, Jan 24, 2019 at 10:18 AM Ian Jackson <
ijack...@chiark.greenend.org.uk> wrote:

> To the Debian Perl maintainers: if I make a patch to make
>   -p -n <>
> use the 3-argument form of open (or equivalent), will you apply it ?
>
> To the Debian security team: would you ship it in a security update ?
>

Wouldn't a less drastic approach be to change the vulnerable scripts to use
<<>> instead of <>?

Mark.

Re: Potentially insecure Perl scripts

[Holger Levsen]

On Thu, Jan 24, 2019 at 03:18:40PM +, Ian Jackson wrote:
> To the Debian Perl maintainers: [...]
> To the Debian security team: [...]

I've read the whole thread and am surprised "talking to upstream" (and
fixing the issue there as well) hasn't really been on the table. :/ Did I
miss that?


-- 
tschüß,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Potentially insecure Perl scripts

[Colin Watson]

On Thu, Jan 24, 2019 at 02:49:29PM -0500, Mark Fowler wrote:
> On Thu, Jan 24, 2019 at 10:18 AM Ian Jackson <
> ijack...@chiark.greenend.org.uk> wrote:
> > To the Debian Perl maintainers: if I make a patch to make
> >   -p -n <>
> > use the 3-argument form of open (or equivalent), will you apply it ?
> >
> > To the Debian security team: would you ship it in a security update ?
> 
> Wouldn't a less drastic approach be to change the vulnerable scripts to use
> <<>> instead of <>?

Do you have a proposal for enumerating all the vulnerable scripts?

Also, <<>> doesn't work if your script expects to continue to support
"-" to mean stdin, because it turns that off along with all the rather
more dangerous magic.  In the case of groff, "-" was specifically
documented in the manual pages of the relevant programs; so I made
essentially the following transformation:

  while (<>) {
...
  }

... into:

  unshift @ARGV, '-' unless @ARGV;
  foreach my $filename (@ARGV) {
my $input;
if ($filename eq '-') {
  $input = \*STDIN;
} elsif (not open $input, '<', $filename) {
  warn $!;
  next;
}
while (<$input>) {
  ...
}
  }

A bit tedious, but seems workable.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Potentially insecure Perl scripts

[Ian Jackson]

Mark Fowler writes ("Re: Potentially insecure Perl scripts"):
> Wouldn't a less drastic approach be to change the vulnerable scripts to use
> <<>> instead of <>?

That is surely a much more drastic change.  It would invoke changing
probably literally millions of scripts.

Even if we care only about scripts which are part of Debian, rather
than scripts which people merely expect to run on Debian (and where
they trust Debian to not blow their leg off), there will probably be
many thousands.

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.

Re: Potentially insecure Perl scripts

[Ian Jackson]

Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> Even if we care only about scripts which are part of Debian, rather
> than scripts which people merely expect to run on Debian (and where
> they trust Debian to not blow their leg off), there will probably be
> many thousands.

I asked codesearch about
   while.*\<\>
and got 10780 results.

That
  - does not include situations where -p and -e are wrong
  - does not include other dangerous uses of <>
but
  - it does probably include some scripts which will never
 see potentially hostile filenames
  - will include some matches in things other than Perl but
 probably not many

I think this does mean that *at least* 10780 locations in Debian would
need to be looked at by a human being to see what to do about them.

I think, effectively, you are proposing a >10780-bug MBF ?

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.

Re: Potentially insecure Perl scripts

[Niels Thykier]

Ian Jackson:
> Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
>> Even if we care only about scripts which are part of Debian, rather
>> than scripts which people merely expect to run on Debian (and where
>> they trust Debian to not blow their leg off), there will probably be
>> many thousands.
> 
> I asked codesearch about
>while.*\<\>
> and got 10780 results.
> 

Hi,

I had a similar thought but tried a slightly more complex pattern:

(while\s*|for(each)?\s*(my)?\s*\$.*)\(.*<>\s*\)

The pattern also tries to cover "for" and "foreach" while also being
more strict to prune false positives (C++ templates, Pascal and SQL trip
naive searches for "<>").

This variant still puts us in the 3000 - 4000 results, which (while
being less than half of the original number) is far more than is likely
to be resolved manually in a reasonable time frame.

Thanks,
~Niels

Re: Potentially insecure Perl scripts

[Guillem Jover]

On Thu, 2019-01-24 at 21:08:00 +, Niels Thykier wrote:
> Ian Jackson:
> > I asked codesearch about
> >while.*\<\>
> > and got 10780 results.
> 
> I had a similar thought but tried a slightly more complex pattern:
> 
> (while\s*|for(each)?\s*(my)?\s*\$.*)\(.*<>\s*\)
> 
> The pattern also tries to cover "for" and "foreach" while also being
> more strict to prune false positives (C++ templates, Pascal and SQL trip
> naive searches for "<>").
> 
> This variant still puts us in the 3000 - 4000 results, which (while
> being less than half of the original number) is far more than is likely
> to be resolved manually in a reasonable time frame.

Oh, and you both are missing . XD

Thanks,
Guillem

Bug#920385: ITP: dmarc-cat -- decode the report sent by various email providers following the DMARC spec

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 

* Package name: dmarc-cat
  Version : 0.9.1
  Upstream Author : Ollivier Robert 
* URL : https://github.com/keltia/dmarc-cat/
* License : BSD-2-clause
  Programming Lang: Golang
  Description : decode the report sent by various email providers following 
the DMARC spec

This utility decodes the standard XML reports sent by providers to the
`rua` record configured in DMARC. It is useful to make sense of
reports that are otherwise very difficult to read.

--

I've tried it out and it was a life saver. I was about to just remove
that record because I couldn't make sense of those reports.

There's a comparable service online, which has a little more
information, but does not do reverse DNS:

https://mxtoolbox.com/DmarcReportAnalyzer.aspx

That online service is, of course, not free software as far as I
know.

I haven't found similar software in Debian, but I could have missed
something.

I will probably co-maintain this with the golang team.

Bug#920387: ITP: golang-github-proglottis-gpgme -- Go wrapper for the GPGME library

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-proglottis-gpgme
  Version : 0.0~git20181127.3b0be09-1
  Upstream Author : James Fargher
* URL : https://github.com/proglottis/gpgme
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go wrapper for the GPGME library

 GPGME (golang) Go wrapper for the GPGME library.
 .
 This library is intended for use with desktop applications. If
 you are looking to add OpenPGP support to a server application
 I suggest you first look at golang.org/x/crypto/openpgp
 (https://godoc.org/golang.org/x/crypto/openpgp).  Installationgo
 get -u github.com/proglottis/gpgme Documentation• godoc
 (https://godoc.org/github.com/proglottis/gpgme)

Dependency for #920385.


signature.asc
Description: PGP signature

Bug#920388: ITP: golang-github-keltia-archive -- Small Go library for handling archives of various types.

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-keltia-archive
  Version : 0.3.3-1
  Upstream Author : Ollivier Robert
* URL : https://github.com/keltia/archive
* License : BSD-3-clause
  Programming Lang: Go
  Description : Small Go library for handling archives of various types.

-- 

Dependency for #920385.



signature.asc
Description: PGP signature

Bug#920389: ITP: golang-github-intel-tfortools -- template scripting support to go programs

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-intel-tfortools
  Version : 0.2.0+git20180102.ec3334c-1
  Upstream Author : Intel Corporation
* URL : https://github.com/intel/tfortools
* License : Apache-2.0
  Programming Lang: Go
  Description : template scripting support to go programs

 Package tfortools provides a set of functions that are designed to make
 it easier for developers to add template based scripting to their command
 line tools.
 .
 Command line tools written in Go often allow users to specify a template
 script to tailor the output of the tool to their specific needs. This can
 be useful both when visually inspecting the data and also when invoking
 command line tools in scripts. The best example of this is go list which
 allows users to pass a template script to extract interesting information
 about Go packages. For example,
 .
 .
 go list -f '{{range .Imports}}{{println .}}{{end}}'
 .
 .
 prints all the imports of the current package.
 .
 The aim of this package is to make it easier for developers to add
 template scripting support to their tools and easier for users of
 these tools to extract the information they need.   It does this by
 augmenting the templating language provided by the standard library
 package text/template in two ways: • It auto generates descriptions of
 the data structures passed as input to a template script for use in help
 messages.  This ensures that help usage information is always up to date
 with the source code.• It provides a suite of convenience functions to
 make it easy for script writers to extract the data they need.  There are
 functions for sorting, selecting rows and columns and generating nicely
 formatted tables.  For example, if a program passed a slice of structs
 containing stock data to a template script, we could use the following
 script to extract the names of the 3 stocks with the highest trade volume.
 .
 .
 {{table (cols (head (sort . "Volume" "dsc") 3) "Name" "Volume")}}
 .
 .
 The output might look something like this:
 .
 .
 Name  Volume Happy Enterprises 6395624278 Big Company
 750 Medium Company300122
 .
 .
 The functions head, sort, tables and col are provided by this package.

-- 

Dependency for #920385.



signature.asc
Description: PGP signature

Bug#920390: ITP: golang-github-ivpusic-grpool -- Lightweight Goroutine pool

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-ivpusic-grpool
  Version : 0.0~git20170804.28957a2-1
  Upstream Author : Ivan Pusic
* URL : https://github.com/ivpusic/grpool
* License : MIT
  Programming Lang: Go
  Description : Lightweight Goroutine pool

 Clients can submit jobs. Dispatcher takes job, and sends it to first
 available worker.  When worker is done with processing job, will be
 returned back to worker pool.
 .
 Number of workers and Job queue size is configurable.

Dependency for #920385.


signature.asc
Description: PGP signature

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-24 15:18:40 +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> > The right answer is to fix the behaviour to be secure and sane by
> > default.  We can arrange for an environment variable for people who
> > want to turn the crazy back on.
> 
> To the Debian Perl maintainers: if I make a patch to make
>   -p -n <>
> use the 3-argument form of open (or equivalent), will you apply it ?

I fear that this is not that simple: I suppose that this will break
scripts that modify @ARGV to make <> secure. :(

Now, perhaps the number of such scripts is close to 0. I don't know.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#920392: ITP: rusty-tags -- generate tags for source code navigation for a cargo project

[Robin Krahl]

Package: wnpp
Severity: wishlist
Owner: Robin Krahl 

* Package name: rusty-tags
  Version : 3.3.0
  Upstream Author : Daniel Trstenjak
* URL : https://github.com/dan-t/rusty-tags
* License : BSD-3-Clause
  Programming Lang: Rust
  Description : generate tags for source code navigation for a cargo project

rusty-tags is a command-line tool that creates tags for source code
navigation using ctags for a cargo project, all of its direct and
indirect dependencies and the Rust standard library.

I intend to package rusty-tags as part of the Rust packaging team.


signature.asc
Description: PGP signature

Work-needing packages report for Jan 25, 2019

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1399 (new: 70)
Total number of packages offered up for adoption: 154 (new: 1)
Total number of packages requested help for: 57 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   6tunnel (#920085), orphaned 3 days ago
 Description: TCP proxy for non-IPv6 applications
 Installations reported by Popcon: 84
 Bug Report URL: https://bugs.debian.org/920085

   afio (#920069), orphaned 3 days ago (non-free)
 Description: archive file manipulation program
 Installations reported by Popcon: 353
 Bug Report URL: https://bugs.debian.org/920069

   agrep (#920119), orphaned 3 days ago (non-free)
 Description: text search tool with support for approximate patterns
 Installations reported by Popcon: 266
 Bug Report URL: https://bugs.debian.org/920119

   apng2gif (#920071), orphaned 3 days ago
 Description: tool for converting APNG images to animated GIF format
 Installations reported by Popcon: 81
 Bug Report URL: https://bugs.debian.org/920071

   bbe (#920055), orphaned 3 days ago
 Description: sed-like editor for binary files
 Installations reported by Popcon: 72
 Bug Report URL: https://bugs.debian.org/920055

   bmf (#920054), orphaned 3 days ago
 Description: e-mail filter for spam that learns
 Installations reported by Popcon: 8
 Bug Report URL: https://bugs.debian.org/920054

   buildtorrent (#920088), orphaned 3 days ago
 Description: command line torrent creation program
 Installations reported by Popcon: 69
 Bug Report URL: https://bugs.debian.org/920088

   cbm (#920077), orphaned 3 days ago
 Description: display the current network traffic in colors
 Installations reported by Popcon: 208
 Bug Report URL: https://bugs.debian.org/920077

   cfourcc (#920122), orphaned 3 days ago
 Description: command line tool for changing FourCC in Microsoft RIFF
   AVI files
 Installations reported by Popcon: 61
 Bug Report URL: https://bugs.debian.org/920122

   colortest (#920078), orphaned 3 days ago
 Description: utilities to test color capabilities of terminal
 Installations reported by Popcon: 248
 Bug Report URL: https://bugs.debian.org/920078

   colortest-python (#920127), orphaned 3 days ago
 Description: utility to test color capabilities of terminal
 Installations reported by Popcon: 97
 Bug Report URL: https://bugs.debian.org/920127

   comprez (#920064), orphaned 3 days ago
 Description: frontend to many compression programs
 Reverse Depends: forensics-extra
 Installations reported by Popcon: 111
 Bug Report URL: https://bugs.debian.org/920064

   copyright-update (#920063), orphaned 3 days ago
 Description: update copyright information in files
 Installations reported by Popcon: 47
 Bug Report URL: https://bugs.debian.org/920063

   corkscrew (#920060), orphaned 3 days ago
 Description: tunnel TCP connections through HTTP proxies
 Installations reported by Popcon: 210
 Bug Report URL: https://bugs.debian.org/920060

   dact (#920115), orphaned 3 days ago
 Description: multi-algorithm compression
 Reverse Depends: forensics-extra
 Installations reported by Popcon: 41
 Bug Report URL: https://bugs.debian.org/920115

   dbar (#920108), orphaned 3 days ago
 Description: general purpose ASCII graphic percentage
   meter/progressbar
 Installations reported by Popcon: 31
 Bug Report URL: https://bugs.debian.org/920108

   ddir (#920066), orphaned 3 days ago
 Description: display hierarchical directory tree
 Installations reported by Popcon: 31
 Bug Report URL: https://bugs.debian.org/920066

   dlume (#920097), orphaned 3 days ago
 Description: simple and easy to use addressbook (GTK+)
 Installations reported by Popcon: 32
 Bug Report URL: https://bugs.debian.org/920097

   dnstracer (#920076), orphaned 3 days ago
 Description: trace DNS queries to the source
 Installations reported by Popcon: 532
 Bug Report URL: https://bugs.debian.org/920076

   dyndns (#920065), orphaned 3 days ago
 Description: dynamic DNS (DDNS) update client implemented in Perl
 Installations reported by Popcon: 100
 Bug Report URL: https://bugs.debian.org/920065

   emelfm2-svg-icons (#920129), orphaned 3 days ago
 Description: icon SVG files from emelfm2 project
 Installations reported by Popcon: 26
 Bug Report URL: https://bugs.debian.org/920129

   flip (#920087), orphaned 3 days ago
 Description: convert text file line endings between Unix and DOS
   formats
 Installations reported by Popcon: 325
 Bug Report URL: https:/

Bug#920395: ITP: difference -- text diffing tool

[Robin Krahl]

Package: wnpp
Severity: wishlist
Owner: Robin Krahl 

* Package name: difference
  Version : 2.0.0
  Upstream Author : Johann Hofmann
* URL : https://github.com/johannhof/difference.rs
* License : MIT
  Programming Lang: Rust
  Description : text diffing tool

difference compares two strings and prints a colorful visual
representation of the diff.

I intend to package difference as part of the Rust packaging team.


signature.asc
Description: PGP signature