Bug#903946: ITP: ukui-power-manager -- power management tool for the UKUI desktop

[handsome_feng]

Package: wnpp
Severity: wishlist
Owner: handsome_feng 

* Package name: ukui-power-manager
  Version : 1.1.1
  Upstream Author : Kobe Lee 
* URL : https://github.com/ukui/ukui-power-manager
* License : GPL-2+, LGPL-2+
  Programming Lang: C
  Description : power management tool for the UKUI desktop

 UKUI Power Manager is a session daemon for the UKUI desktop
 that takes care of system or desktop events related to power, and
 triggers actions accordingly. Its philosophy is to completely hide
 these complex tasks and only show some settings important to the user.
 .
 The UKUI power manager displays and manages battery status, power plug
 events, display brightness, CPU, graphics card and hard disk drive
 power saving, and can trigger suspend-to-RAM, hibernate or shutdown
 events, all integrated to other components of the UKUI desktop.

 This package will be maintained by the Kylin Team.

Bug#903944: ITP: ukui-settings-daemon -- daemon handling the UKUI session settings

[handsome_feng]

Package: wnpp
Severity: wishlist
Owner: handsome_feng 

* Package name: ukui-settings-daemon
  Version : 1.1.6
  Upstream Author : Kylin Team 
* URL : https://github.com/ukui/ukui-settings-daemon
* License : GPL-2+, GPL-3+, LGPL-2+
  Programming Lang: C
  Description : daemon handling the UKUI session settings

 This package contains the daemon which is responsible for setting the
 various parameters of a UKUI session and the applications that run
 under it.
 It also sets various application settings through X resources and
 freedesktop.org XSETTINGS.

 This package will be maintained by the Kylin Team.

Bug#903943: ITP: ukui-panel -- launcher and docking facility for UKUI

[handsome_feng]

Package: wnpp
Severity: wishlist
Owner: handsome_feng 

* Package name: ukui-panel
  Version : 1.1.4
  Upstream Author : quankang 
* URL : https://github.com/ukui/ukui-panel
* License : GPL-2
  Programming Lang: C
  Description : launcher and docking facility for UKUI

The UKUI Panel is an essential part of the UKUI Desktop, providing toolbar-like
“ panels”  which can be attached to the sides of your desktop. They are used to
launch applications and embed a number of other functions, such as quick launch
icons, the clock, the notification area, volume controls and the battery charge
indicator, and utilities ranging from weather forecast to system monitoring.

This package will be maintained by the Kylin Team.

Bug#903942: ITP: ukui-menus -- implementation of the freedesktop menu specification for UKUI

[handsome_feng]

Package: wnpp
Severity: wishlist
Owner: handsome_feng 

* Package name: ukui-menus
  Version : 1.1.3
  Upstream Author : penghuan 
* URL : https://github.com/ukui/ukui-menus
* License : GPL-2
  Programming Lang: C
  Description : implementation of the freedesktop menu specification for
UKUI

ukui-menus contains an implementation of the draft
"Desktop Menu Specification" from freedesktop.org:
.
http://www.freedesktop.org/Standards/menu-spec
.
Also contained here are the UKUI menu layout configuration files, .director
y files and assorted menu related utility programs.
.
This package will be maintained by the Kylin Team.

Bug#903922: ITP: ruby-io-like -- Provides the methods of an IO object based upon on a few simple methods

[Mujeeb cpy]

Package: wnpp
Severity: wishlist
Owner: Mujeeb Rahman K 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ruby-io-like
  Version : 0.3.0
  Upstream Author : Jeremy Bopp
* URL : https://rubygems.org/gems/io-like
* License : GPL-2 or Ruby License
  Programming Lang: Ruby
  Description :  provides the methods of an IO object based upon
on a few simple methods provided by the including class:
unbuffered_read, unbuffered_write, and unbuffered_seek. These methods
provide the underlying read, write, and seek support respectively, and
only the method or methods necessary to the correct operation of the
IO aspects of the including class need to be provided. Missing
functionality will cause the resulting object to appear read-only,
write-only, and/or unseekable depending on which underlying methods
are absent. Additionally, read and write operations which are buffered
in IO are buffered with independently configurable buffer sizes.
Duplexed objects (those with separate read and write streams) are also
supported.


This ruby gem is part of dependency chain of rails 5

I want to maintain this as part of ruby team

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

On Mon, 16 Jul 2018 at 18:39:59 +0100, Chris Lamb wrote:
> So, whilst I will be at DebCamp too (yay) I unfortunately won't have
> any hardware to test with and for various reasons I should keep
> commitments low at this point.

Sure thing!  I was planning to do some triaging anyway :-)  (#888916 has
been open for a while already and it's unfortunate that we didn't find
time to provide any follow-up yet.)

> (Can we get something into shape on a branch for Kyle to test, or are
> the bug references you cite above enough?)

AFAIK we don't have anything to show other than the two bugs and the
link to the respective repositories, but hopefully we'll have something
after DebCamp.  I'll poke you once this is the case! :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Dear Guilhem,

> > My gut tells me we should incoropate OpenPGP support directly into
> 
> I assume you mean OpenPGP *smartcard* here

Yes, mea culpa; wasn't paying attention! :)

> Since there is already #888916 open requesting merging of some initramfs
> scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
> polite of us cryptsetup package maintainers to review Rian's code as
> well before including anything.

Of course and I totally agree with this and your following paragraphs.

So, whilst I will be at DebCamp too (yay) I unfortunately won't have
any hardware to test with and for various reasons I should keep
commitments low at this point.

(Can we get something into shape on a branch for Kyle to test, or are
the bug references you cite above enough?)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

Hi Chris,

On Mon, 16 Jul 2018 at 10:15:47 +0100, Chris Lamb wrote:
>> Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the
>> hook is copying private key material to the initramfs, but […]
> 
> My gut tells me we should incoropate OpenPGP support directly into

I assume you mean OpenPGP *smartcard* here: symmetric OpenPGP encryption
is supported 2:1.0.3-3 released 12 years ago (and that's the hook and
boot scripts which Peter then Erik forked) :-)

> Does that work for you in principle Guilhem? I'm assuming we can
> "just" merge in the aforementioned package (!) and fix up some of the
> issues, including the umask one you already outlined.
> 
> What would be the next steps here? :)

I'm in favor of adding OpenPGP smartcard support to src:cryptsetup, but
not more that one set of hook & boot scripts.

Since there is already #888916 open requesting merging of some initramfs
scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
polite of us cryptsetup package maintainers to review Rian's code as
well before including anything.

We've been quite busy lately with the massive refactoring and the couple
of regressions that followed, but I hope to take a closer look at both
proposals during DebCamp next week.  Naturally, help is welcome :-)

I'm not sure it's worth shipping another “Architecture: all” binary
package to src:cryptsetup, though (as opposed to including the keyscript
to cryptsetup-run and the initramfs bits to cryptsetup-initramfs, like
we're doing for decrypt_gnupg, decrypt_keyctl, decrypt_opensc, etc.).
Sure, splitting cryptsetup-run and cryptsetup-initramfs further means we
can assign more fine-grained dependencies, but in the end it'll just be
a tiny shell script in each package, so is it worth the effort?  Also
`update-initramfs -u` will complain if the required binaries (pcsd, gpg,
etc.) cannot be copied; and the user has to install these to be able to
set up the mapping in the first place.

(If we add another “Architecture: all” binary package we should also
split cryptsetup-run and cryptsetup-initramfs for the sake of
consistency.  Not sure it's worth the effort, but now-ish would be a
good time to do this since we've already split cryptsetup-initramfs
away.  I personally don't have strong feelings either way; CC'ing Jonas
who might have a different opinion.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Processed: retitle to RFP: smith -- fonts and keyboards build and test framework

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 860155 RFP: smith -- fonts and keyboards build and test framework
Bug #860155 [wnpp] ITP: smith -- fonts and keyboards build and test framework
Changed Bug title to 'RFP: smith -- fonts and keyboards build and test 
framework' from 'ITP: smith -- fonts and keyboards build and test framework'.
> noowner 860155
Bug #860155 [wnpp] RFP: smith -- fonts and keyboards build and test framework
Removed annotation that Bug was owned by Nicolas Spalinger 
.
> stop
Stopping processing here.

Please contact me if you need assistance.
-- 
860155: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860155
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#903913: ITP: eclipse-jdt-core -- Eclipse Java Development Tools Core

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: eclipse-jdt-core
  Version : 4.7.3
  Upstream Author : Eclipse Foundation, Inc.
* URL : https://www.eclipse.org/jdt/core/
* License : EPL-1.0
  Programming Lang: Java
  Description : Eclipse Java Development Tools Core

Eclipse JDT Core is the Java infrastructure of the Eclipse Java IDE.
It includes:
 * An incremental Java compiler. Implemented as an Eclipse builder, it is based
   on technology evolved from VisualAge for Java compiler. In particular, it
   allows to run and debug code which still contains unresolved errors.
 * A Java Model that provides API for navigating the Java element tree.
   The Java element tree defines a Java centric view of a project. It surfaces
   elements like package fragments, compilation units, binary classes, types,
   methods, fields.
 * A Java Document Model providing API for manipulating a structured Java
   source document.
 * Code assist and code select support.
 * An indexed based search infrastructure that is used for searching, code
   assist, type hierarchy computation, and refactoring. The Java search engine
   can accurately find precise matches either in sources or binaries.
 * Evaluation support either in a scrapbook page or a debugger context.
 * Source code formatter.

The JDT Core infrastructure has no built-in JDK version dependencies, it also
does not depend on any particular Java UI and can be run headless.


This package will be maintained by the Java Team.

Bug#903815: ITP: pw -- A simple command-line password manager

[Andrey Rahmatullin]

On Mon, Jul 16, 2018 at 04:45:58PM +0200, Philipp Kern wrote:
> > Can we assume you didn't look at the code trying to follow the logic and
> > you don't have the full picture?
> 
> Can we please stop here? It takes grace to take back the request.
Sure, but this email was sent before receiving that email.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#903815: ITP: pw -- A simple command-line password manager

[Philipp Kern]

On 2018-07-16 15:58, Andrey Rahmatullin wrote:
Can we assume you didn't look at the code trying to follow the logic 
and

you don't have the full picture?


Can we please stop here? It takes grace to take back the request.

Kind regards and thanks
Philipp Kern

Bug#903911: ITP: pilon-non-free -- automated genome assembly improvement and variant detection tool

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: pilon-non-free
  Version : 1.22
  Upstream Author : Copyright: Copyright 2012-2017 Broad Institute, Inc.
* URL : https://github.com/broadinstitute/pilon/wiki
* License : GPL-2
  Programming Lang: Java
  Description : automated genome assembly improvement and variant detection 
tool
 Pilon is a software tool which can be used to:
  * Automatically improve draft assemblies
  * Find variation among strains, including large event detection
 Pilon requires as input a FASTA file of the genome along with one or more
 BAM files of reads aligned to the input FASTA file. Pilon uses read
 alignment analysis to identify inconsistencies between the input genome and
 the evidence in the reads. It then attempts to make improvements to the
 input genome, including:
  * Single base differences
  * Small indels
  * Larger indel or block substitution events
  * Gap filling
  * Identification of local misassemblies, including optional opening
of new gaps
 .
 The code of pilon is actually free but currently there is no method
 to build the JAR from the scala source in Debian.  This package is
 supposed to be replaced by a pilon package once it can be build from
 source (see bug #873341).

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/pilon-non-free
It is planed to replace this package pilon-non-free by a pilon
package once sbt will be usable again (see #873341).  Unfortunately
it is expected that this will take way longer than expected
(see the discussion on debian-java list).

Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

On Mon, Jul 16, 2018 at 4:08 PM Andrey Rahmatullin  wrote:

> On Mon, Jul 16, 2018 at 03:49:18PM +0200, Dashamir Hoxha wrote:
> > > > > ++ mktemp -d /dev/shm/pw.sh.X
> > > > > + WORKDIR=/dev/shm/pw.sh.JHasAYH9zwYz1
> > > > > [...]
> > > > > + decrypt /home/pkern/.pw/pw.tgz
> > > > > + local archive=/home/pkern/.pw/pw.tgz
> > > > > + local 'opts=--quiet --yes --batch '
> > > > > + [[ -z '' ]]
> > > > > + gpg2 --quiet --yes --batch --passphrase-fd 0
> > > /home/pkern/.pw/pw.tgz.gpg
> > > > > + local err=0
> > > > > + [[ 0 -ne 0 ]]
> > > > > + tar -xzf /home/pkern/.pw/pw.tgz -C /dev/shm/pw.sh.JHasAYH9zwYz1
> > > > > + rm -f /home/pkern/.pw/pw.tgz
> > > > >
> > > >
> > > > So, you have not looked at the code trying to follow the logic.
> > > > You have just tried to debug it. This way you cannot get the full
> > > picture.
> > > > But  nevertheless it is useful for finding ways to break the script.
> > > > By the way, you may notice that *there is* error checking there.
> > > >
> > > > This clearly writes the unencrypted tarball out to disk.
> > > > >
> > > >
> > > > It writes to `/dev/shm` which is not disk.
> > > So /home/pkern/.pw/pw.tgz is not "the unencrypted tarball"?
> > >
> >
> > Now I see.
> Can we assume you didn't look at the code trying to follow the logic and
> you don't have the full picture?
>

Yes you can. I just looked at the example provided, but did not look
carefully enough.


> --
> WBR, wRAR
>

Bug#903815: ITP: pw -- A simple command-line password manager

[Andrey Rahmatullin]

On Mon, Jul 16, 2018 at 03:49:18PM +0200, Dashamir Hoxha wrote:
> > > > ++ mktemp -d /dev/shm/pw.sh.X
> > > > + WORKDIR=/dev/shm/pw.sh.JHasAYH9zwYz1
> > > > [...]
> > > > + decrypt /home/pkern/.pw/pw.tgz
> > > > + local archive=/home/pkern/.pw/pw.tgz
> > > > + local 'opts=--quiet --yes --batch '
> > > > + [[ -z '' ]]
> > > > + gpg2 --quiet --yes --batch --passphrase-fd 0
> > /home/pkern/.pw/pw.tgz.gpg
> > > > + local err=0
> > > > + [[ 0 -ne 0 ]]
> > > > + tar -xzf /home/pkern/.pw/pw.tgz -C /dev/shm/pw.sh.JHasAYH9zwYz1
> > > > + rm -f /home/pkern/.pw/pw.tgz
> > > >
> > >
> > > So, you have not looked at the code trying to follow the logic.
> > > You have just tried to debug it. This way you cannot get the full
> > picture.
> > > But  nevertheless it is useful for finding ways to break the script.
> > > By the way, you may notice that *there is* error checking there.
> > >
> > > This clearly writes the unencrypted tarball out to disk.
> > > >
> > >
> > > It writes to `/dev/shm` which is not disk.
> > So /home/pkern/.pw/pw.tgz is not "the unencrypted tarball"?
> >
> 
> Now I see.
Can we assume you didn't look at the code trying to follow the logic and
you don't have the full picture?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

On Mon, Jul 16, 2018 at 3:45 PM Philipp Kern  wrote:

> On 16.07.2018 15:14, Dashamir Hoxha wrote:
> > On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern  > > wrote:
> >
> > rather than trying to appeal to authority like Marc - I could have
> been
> > wrong -, I will point out that my first point was not actually
> addressed
> > at all:
> >
> > ++ mktemp -d /dev/shm/pw.sh.X
> > + WORKDIR=/dev/shm/pw.sh.JHasAYH9zwYz1
> > [...]
> > + decrypt /home/pkern/.pw/pw.tgz
> > + local archive=/home/pkern/.pw/pw.tgz
> > + local 'opts=--quiet --yes --batch '
> > + [[ -z '' ]]
> > + gpg2 --quiet --yes --batch --passphrase-fd 0
> > /home/pkern/.pw/pw.tgz.gpg
> > + local err=0
> > + [[ 0 -ne 0 ]]
> > + tar -xzf /home/pkern/.pw/pw.tgz -C /dev/shm/pw.sh.JHasAYH9zwYz1
> > + rm -f /home/pkern/.pw/pw.tgz
> >
> >
> > So, you have not looked at the code trying to follow the logic.
>
> Of course I did. Can we stop with the ad hominems and implying that the
> other party is stupid, please?
>
> > You have just tried to debug it. This way you cannot get the full
> picture.
> > But  nevertheless it is useful for finding ways to break the script.
> > By the way, you may notice that *there is* error checking there.
> >
> > This clearly writes the unencrypted tarball out to disk.
> >
> >
> > It writes to `/dev/shm` which is not disk. It writes to a random
> > temporary directory, so that it cannot be guessed. It removes
> > the unencrypted content as soon as the operation is performed.
> > All this happens almost instantly, it never stays unencrypted
> > for a long time. It is almost the same thing as using a pipe (|).
> > What is wrong here? I have been using it for 2-3 years and
> > never had a problem.
>
> No, it doesn't. /home/pkern/.pw/pw.tgz is not on /dev/shm. If it were a
> pipe, there wouldn't be a problem. But alas, there isn't one and it
> totally isn't the same as using a pipe.
>

You are right. Now I see the problem. I revoke the package request.
I also ask your pardon for any unkind words.

But I still think that this is not a problem of Bash, and no other language
could have done it better. It is my mistake.

Best regards,
Dashamir


>
> Kind regards
> Philipp Kern
>

Bug#903815: ITP: pw -- A simple command-line password manager

[Andrey Rahmatullin]

On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote:
> > ++ mktemp -d /dev/shm/pw.sh.X
> > + WORKDIR=/dev/shm/pw.sh.JHasAYH9zwYz1
> > [...]
> > + decrypt /home/pkern/.pw/pw.tgz
> > + local archive=/home/pkern/.pw/pw.tgz
> > + local 'opts=--quiet --yes --batch '
> > + [[ -z '' ]]
> > + gpg2 --quiet --yes --batch --passphrase-fd 0 /home/pkern/.pw/pw.tgz.gpg
> > + local err=0
> > + [[ 0 -ne 0 ]]
> > + tar -xzf /home/pkern/.pw/pw.tgz -C /dev/shm/pw.sh.JHasAYH9zwYz1
> > + rm -f /home/pkern/.pw/pw.tgz
> >
> 
> So, you have not looked at the code trying to follow the logic.
> You have just tried to debug it. This way you cannot get the full picture.
> But  nevertheless it is useful for finding ways to break the script.
> By the way, you may notice that *there is* error checking there.
> 
> This clearly writes the unencrypted tarball out to disk.
> >
> 
> It writes to `/dev/shm` which is not disk. 
So /home/pkern/.pw/pw.tgz is not "the unencrypted tarball"?

> All this happens almost instantly, it never stays unencrypted
> for a long time. 
This is just wrong.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

On Mon, Jul 16, 2018 at 3:43 PM Andrey Rahmatullin  wrote:

> On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote:
> > > ++ mktemp -d /dev/shm/pw.sh.X
> > > + WORKDIR=/dev/shm/pw.sh.JHasAYH9zwYz1
> > > [...]
> > > + decrypt /home/pkern/.pw/pw.tgz
> > > + local archive=/home/pkern/.pw/pw.tgz
> > > + local 'opts=--quiet --yes --batch '
> > > + [[ -z '' ]]
> > > + gpg2 --quiet --yes --batch --passphrase-fd 0
> /home/pkern/.pw/pw.tgz.gpg
> > > + local err=0
> > > + [[ 0 -ne 0 ]]
> > > + tar -xzf /home/pkern/.pw/pw.tgz -C /dev/shm/pw.sh.JHasAYH9zwYz1
> > > + rm -f /home/pkern/.pw/pw.tgz
> > >
> >
> > So, you have not looked at the code trying to follow the logic.
> > You have just tried to debug it. This way you cannot get the full
> picture.
> > But  nevertheless it is useful for finding ways to break the script.
> > By the way, you may notice that *there is* error checking there.
> >
> > This clearly writes the unencrypted tarball out to disk.
> > >
> >
> > It writes to `/dev/shm` which is not disk.
> So /home/pkern/.pw/pw.tgz is not "the unencrypted tarball"?
>

Now I see.


>
> > All this happens almost instantly, it never stays unencrypted
> > for a long time.
> This is just wrong.
>

You are right.


>
> --
> WBR, wRAR
>

Bug#903815: ITP: pw -- A simple command-line password manager

[Philipp Kern]

On 16.07.2018 15:14, Dashamir Hoxha wrote:
> On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern  > wrote:
> 
> rather than trying to appeal to authority like Marc - I could have been
> wrong -, I will point out that my first point was not actually addressed
> at all:
> 
> ++ mktemp -d /dev/shm/pw.sh.X
> + WORKDIR=/dev/shm/pw.sh.JHasAYH9zwYz1
> [...]
> + decrypt /home/pkern/.pw/pw.tgz
> + local archive=/home/pkern/.pw/pw.tgz
> + local 'opts=--quiet --yes --batch '
> + [[ -z '' ]]
> + gpg2 --quiet --yes --batch --passphrase-fd 0
> /home/pkern/.pw/pw.tgz.gpg
> + local err=0
> + [[ 0 -ne 0 ]]
> + tar -xzf /home/pkern/.pw/pw.tgz -C /dev/shm/pw.sh.JHasAYH9zwYz1
> + rm -f /home/pkern/.pw/pw.tgz
> 
> 
> So, you have not looked at the code trying to follow the logic.

Of course I did. Can we stop with the ad hominems and implying that the
other party is stupid, please?

> You have just tried to debug it. This way you cannot get the full picture.
> But  nevertheless it is useful for finding ways to break the script.
> By the way, you may notice that *there is* error checking there.
> 
> This clearly writes the unencrypted tarball out to disk.
> 
> 
> It writes to `/dev/shm` which is not disk. It writes to a random
> temporary directory, so that it cannot be guessed. It removes
> the unencrypted content as soon as the operation is performed.
> All this happens almost instantly, it never stays unencrypted
> for a long time. It is almost the same thing as using a pipe (|).
> What is wrong here? I have been using it for 2-3 years and
> never had a problem.

No, it doesn't. /home/pkern/.pw/pw.tgz is not on /dev/shm. If it were a
pipe, there wouldn't be a problem. But alas, there isn't one and it
totally isn't the same as using a pipe.

Kind regards
Philipp Kern

Bug#903815: Bug#903880: Bug#903815: ITP: pw -- A simple command-line password manager

[Roberto C . Sánchez]

On Mon, Jul 16, 2018 at 02:36:17PM +0200, Dashamir Hoxha wrote:
>On Mon, Jul 16, 2018 at 2:21 PM Holger Levsen <[1]hol...@layer-acht.org>
>wrote:
> 
>  On Sun, Jul 15, 2018 at 12:41:36PM +0200, Carsten Schoenert wrote:
>  > Hmm, do you have tried to validate your shell code?
>  > [2]https://www.shellcheck.net/
>  > I just pasted
>  > [3]https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh
>  into
>  > and got quite a lot of problematic remarks.
> 
>  I've also done this now and must say/add "ouch":
> 
>I have already answered this. Only one of the suggestions might be useful.
>If everything was clean, according to shellcheck, this wouldn't mean at
>all
>that the program is safe and secure and takes care of all the cases.
>I know what is going on in my program better than the mindless shellcheck.
> 
I've been following this thread and it is very difficult for me to
understand why constructive criticism from others is so difficult for
you to accept.

In general, the community of Debian Developers is very concerned with
producing a high quality distribution and also with supporting free
software development.  The fact that some have taken the time and
interest to critique your work is very positive.  Yet, you choose to
perceive their critiques as an attack and then launch your own
counter-attack.

I don't mean to lecture, but your responses to several of the messages
in this thread indicate that you are likely a younger/junior developer.
That is not intended to be disparraging, but rather I am trying to
understand the reason for the way in which you have responded in this
thread.

In my own case, I know that my attitude in response to critique was much
like yours, when I was still a young developer who thought he knew it
all.  Over the years, though, I have come to understand that I know far
less than I thought I knew when I was younger.  That is, the world of
programming knowledge far larger than I originally understood it to be.
Even now, as a very experienced and senior developer, I frequently seek
the advice and review of colleagues whenever I make significant changes
to existing code, write new code, etc.  I can tell you that I am a far
better and more productive developer as a result.

Another thing which seems to indicate that you are not particularly
mature as a developer is the manner in which you quickly dismiss the
results of static analysis.  Certainly, there are instances where the
tools do not fully understand the meaning of your code and provide false
alarms.  However, I have come to realize that static analysis is right
for more than it is wrong.  So, I have adopted the position that unless
I can clearly articulate a good reason why the static analysis is wrong
and my approach is better (and defend that reason to other programmers
more senior than myself), I defer to the tool and fix the code.  I do
this in several programming languages.

Additionally, the argument that you make, "If everything was clean,
according to shellcheck, this wouldn't mean at all that the program is
safe and secure and takes care of all the cases," is totally invalid.
The fact that the tool fails to catch everything is not justification to
automatically reject the things that it does catch.  If the tool is
consistently wrong, contact the developer of the tool with a sample of
your code that you think the tool is incorrectly flagging, and convince
the tool developer (using a technical and supported argument) why the
tool should be updated.  Your discussion with the tool developer might
reveal to you that there is a defect in your own code that you did not
understand.

I encourage you, for your own benefit to accept the criticism from
myself and others in the spirit in which it was intended: to help you
produce a better free software tool and to improve as a developer.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#903815: ITP: pw -- A simple command-line password manager

[Roberto C . Sánchez]

On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote:
>On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern <[1]pk...@debian.org> wrote:
> 
>  This clearly writes the unencrypted tarball out to disk.
> 
>It writes to `/dev/shm` which is not disk.

That is not a valid assumption.  You have no way of knowing the device
behind /dev/shm.

> It writes to a random
>temporary directory, so that it cannot be guessed. It removes
>the unencrypted content as soon as the operation is performed.

Unless the operation is atomic there is a possibility it can be
interrupted.

>All this happens almost instantly, it never stays unencrypted
>for a long time.

Ibid.

> It is almost the same thing as using a pipe (|).
>What is wrong here?

It is not the same thing and it is based on several invalid/flawed
assumptions.

> I have been using it for 2-3 years and
>never had a problem.
> 

That doesn't make it correct code.  I spend most of my day in code bases
authored by other people.  I consistently find bugs that have been in
production, unreported, for 10 or more years.  A bug is still a bug when
it is found and identified, even if it has never manifested itself in
the real world.  If you doubt that, please review the recent news
surrounding the SPECTRE and MELTDOWN vulnerabilities.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

On Mon, Jul 16, 2018 at 3:03 PM Philipp Kern  wrote:

> On 16.07.2018 14:24, Dashamir Hoxha wrote:
> > I have the same answer that I gave to Philipp. He has not looked close
> > enough to the code, and has not tried to follow its logic.
> > For example, error *messages* of `tar` are suppressed, not the errors
> > themselves. The result of the command is checked afterwards.
> > Etc. we can discuss them later.
>
> As much as I would have liked to not reply, but alas, another ad hominem.
>
> The result of tar is not checked, no. The result of gpg is checked. I
>

Yes, but this is because `gpg` will fail if `tar` fails.


> think the case I'm worried about is a race on ~/.pw/pw.tgz where between
> archive_unlock and archive_lock pw.tgz is set - say - 0400 and tar fails
> to write.
>
> That said, because you are so much into proofs:
>
> > pkern@vsrv ~/pw/src % ./pw.sh
> > Passphrase for archive '/home/pkern/.pw/pw.tgz':
> > Commands:
> > gen, set, ls, get, show, edit, find, grep, rm, mv, cp, log, help
> > Type q to quit, p to change the passphrase.
> > pw> ls
> > bar
> > foo
> > pw> q
> > pkern@vsrv ~/pw/src % cat tar
> > #!/bin/sh
> > exit 1
> > pkern@vsrv ~/pw/src % PATH=.:$PATH ./pw.sh
> > Passphrase for archive '/home/pkern/.pw/pw.tgz':
> > Commands:
> > gen, set, ls, get, show, edit, find, grep, rm, mv, cp, log, help
> > Type q to quit, p to change the passphrase.
> > pw> ls
> > pw> gen foo
> > ./pw.sh: line 145: xclip: command not found
> > ./pw.sh: line 145: echo: write error: Broken pipe
> > Error: Could not copy data to the clipboard
> > gpg: can't open '/home/pkern/.pw/pw.tgz': No such file or directory
> > gpg: symmetric encryption of '/home/pkern/.pw/pw.tgz' failed: No such
> file or directory
>

This is not a realistic example. You corrupt the `tar` command and then
expect
the program to work well. You might as well delete manually the archive
file and
then expect the program to work well.

But as soon as tar writes incomplete output (which it totally can, it's
> a Tape ARchiver) you have silent corruption.
>

It may happen, but the chances are so small.
I have never heard of `tar` command (or any command) failing randomly
on their own, without any reason.
Anyway, it doesn't hurt to try and make the operations more transactional.

Regards,
Dashamir

Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern  wrote:

> Hi,
>
> rather than trying to appeal to authority like Marc - I could have been
> wrong -, I will point out that my first point was not actually addressed
> at all:
>
> ++ mktemp -d /dev/shm/pw.sh.X
> + WORKDIR=/dev/shm/pw.sh.JHasAYH9zwYz1
> [...]
> + decrypt /home/pkern/.pw/pw.tgz
> + local archive=/home/pkern/.pw/pw.tgz
> + local 'opts=--quiet --yes --batch '
> + [[ -z '' ]]
> + gpg2 --quiet --yes --batch --passphrase-fd 0 /home/pkern/.pw/pw.tgz.gpg
> + local err=0
> + [[ 0 -ne 0 ]]
> + tar -xzf /home/pkern/.pw/pw.tgz -C /dev/shm/pw.sh.JHasAYH9zwYz1
> + rm -f /home/pkern/.pw/pw.tgz
>

So, you have not looked at the code trying to follow the logic.
You have just tried to debug it. This way you cannot get the full picture.
But  nevertheless it is useful for finding ways to break the script.
By the way, you may notice that *there is* error checking there.

This clearly writes the unencrypted tarball out to disk.
>

It writes to `/dev/shm` which is not disk. It writes to a random
temporary directory, so that it cannot be guessed. It removes
the unencrypted content as soon as the operation is performed.
All this happens almost instantly, it never stays unencrypted
for a long time. It is almost the same thing as using a pipe (|).
What is wrong here? I have been using it for 2-3 years and
never had a problem.

Now you might say "I will fix that". But I think the behavior in this
> thread was sufficient evidence to not package this in Debian. I know it
> is hard to deal with criticism and I could have phrased my mail
> differently, but this is clearly not the way. What if there is another
> contentious bug? Will you also insult your users and your fellow
> developers (no matter how senior)?
>

You comments showed that you did not study it carefully, it is not hard
to deal with criticism. For example you claimed there is no error handling,
which is not true.

I have almost 20 years programming experience, and have worked many
years with bash scripting, using it in unconventional ways as well (which
make you shy away from it). Maybe you have more experience than me
but you have to show it on your comments.

I could not have phrased it better than Simon with "let's not try to
> audit scripts without `set -e`" and his other point of not using shell
> scripts for non-trivial matters. Yes, it's a valid language. Yes, people
> can write good scripts in it. But it is very hard and this thread has
> not given me evidence that the creation process of this script mastered
> it. Especially how hard it is to reason about a script that can fail
> silently in all places. Especially if it's something that handles a
> user's secrets.
>

Let's agree that we don't agree about the usefulness of `set -e`
and about the usefulness of Bash for serious matters.

Regards,
Dashamir


>
> > Whoever stops auditing this Bash application because it does not> start
> with `set -e`, does not have the right skills and experience
> for> reviewing/auditing it.
> And these ad hominems are just unhelpful.
>
> Kind regards
> Philipp Kern
>

Bug#903815: ITP: pw -- A simple command-line password manager

[Philipp Kern]

On 16.07.2018 14:24, Dashamir Hoxha wrote:
> I have the same answer that I gave to Philipp. He has not looked close
> enough to the code, and has not tried to follow its logic.
> For example, error *messages* of `tar` are suppressed, not the errors
> themselves. The result of the command is checked afterwards.
> Etc. we can discuss them later.

As much as I would have liked to not reply, but alas, another ad hominem.

The result of tar is not checked, no. The result of gpg is checked. I
think the case I'm worried about is a race on ~/.pw/pw.tgz where between
archive_unlock and archive_lock pw.tgz is set - say - 0400 and tar fails
to write.

That said, because you are so much into proofs:

> pkern@vsrv ~/pw/src % ./pw.sh
> Passphrase for archive '/home/pkern/.pw/pw.tgz':
> Commands:
> gen, set, ls, get, show, edit, find, grep, rm, mv, cp, log, help
> Type q to quit, p to change the passphrase.
> pw> ls
> bar
> foo
> pw> q
> pkern@vsrv ~/pw/src % cat tar
> #!/bin/sh
> exit 1
> pkern@vsrv ~/pw/src % PATH=.:$PATH ./pw.sh
> Passphrase for archive '/home/pkern/.pw/pw.tgz':
> Commands:
> gen, set, ls, get, show, edit, find, grep, rm, mv, cp, log, help
> Type q to quit, p to change the passphrase.
> pw> ls
> pw> gen foo
> ./pw.sh: line 145: xclip: command not found
> ./pw.sh: line 145: echo: write error: Broken pipe
> Error: Could not copy data to the clipboard
> gpg: can't open '/home/pkern/.pw/pw.tgz': No such file or directory
> gpg: symmetric encryption of '/home/pkern/.pw/pw.tgz' failed: No such file or 
> directory

But as soon as tar writes incomplete output (which it totally can, it's
a Tape ARchiver) you have silent corruption.

Kind regards
Philipp Kern

Processed: RFS: wannier90/2.1.0 -- maximally localized Wannier functions

[Debian Bug Tracking System]

Processing control commands:

> block 578829 by -1
Bug #578829 [wnpp] ITP: wannier90 -- Maximally Localized Wannier Functions
578829 was not blocked by any bugs.
578829 was not blocking any bugs.
Added blocking bug(s) of 578829: 903904

-- 
578829: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578829
903904: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903904
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#903815: Bug#903880: Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

On Mon, Jul 16, 2018 at 2:21 PM Holger Levsen  wrote:

> On Sun, Jul 15, 2018 at 12:41:36PM +0200, Carsten Schoenert wrote:
> > Hmm, do you have tried to validate your shell code?
> > https://www.shellcheck.net/
> > I just pasted
> > https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh into
> > and got quite a lot of problematic remarks.
>
> I've also done this now and must say/add "ouch":
>

I have already answered this. Only one of the suggestions might be useful.
If everything was clean, according to shellcheck, this wouldn't mean at all
that the program is safe and secure and takes care of all the cases.
I know what is going on in my program better than the mindless shellcheck.


>
> $ sudo apt install shellcheck
> $ curl -s https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh
> | shellcheck -
>
> In - line 26:
> $GPG --symmetric $opts --cipher-algo=AES256 \
>  ^-- SC2086: Double quote to prevent globbing and
> word splitting.
>
>
> In - line 31:
> $GPG --encrypt $opts --use-agent --no-encrypt-to \
>^-- SC2086: Double quote to prevent globbing and
> word splitting.
>
>
> In - line 32:
> $recipients "$archive"
> ^-- SC2086: Double quote to prevent globbing and word
> splitting.
>
>
> In - line 39:
> $GPG $opts --passphrase-fd 0 "$archive.gpg" <<< "$PASSPHRASE"
>  ^-- SC2086: Double quote to prevent globbing and word
> splitting.
>
>
> In - line 41:
> $GPG --decrypt $opts --use-agent --output="$archive" "$archive.gpg"
>^-- SC2086: Double quote to prevent globbing and
> word splitting.
>
>
> In - line 71:
> make_workdir
> ^-- SC2119: Use make_workdir "$@" if function's $1 should mean
> script's $1.
>
>
> In - line 91:
> make_workdir
> ^-- SC2119: Use make_workdir "$@" if function's $1 should mean
> script's $1.
>
>
> In - line 144:
> local before="$(xclip -o -selection "$X_SELECTION" 2>/dev/null |
> base64)"
>   ^-- SC2155: Declare and assign separately to avoid masking
> return values.
>
>
> In - line 149:
> local now="$(xclip -o -selection "$X_SELECTION" | base64)"
>   ^-- SC2155: Declare and assign separately to avoid masking
> return values.
>
>
> In - line 166:
> make_workdir() {
> ^-- SC2120: make_workdir references arguments, but none are ever passed.
>
>
> In - line 189:
> find "$WORKDIR" -type f -exec $SHRED {} +
>   ^-- SC2086: Double quote to
> prevent globbing and word splitting.
>
>
> In - line 200:
> [[ -f "$platform_file" ]] && source "$platform_file"
>  ^-- SC1090: Can't follow non-constant source.
> Use a directive to specify location.
>
>
> In - line 346:
> local pass="$(cat "$WORKDIR/$path" | head -n 1)"
>   ^-- SC2155: Declare and assign separately to avoid masking
> return values.
>   ^-- SC2002: Useless cat. Consider 'cmd < file |
> ..' or 'cmd file | ..' instead.
>
>
> In - line 569:
> GPG_KEYS="$@"
>  ^-- SC2124: Assigning an array to a string! Assign as array,
> or use * instead of @ to concatenate.
>
>
> In - line 584:
> $GPG $GPG_OPTS --gen-key
>  ^-- SC2086: Double quote to prevent globbing and word splitting.
>
>
> In - line 606:
> | while read pwfile
> ^-- SC2162: read without -r will mangle backslashes.
>
>
> In - line 624:
> [[ -f "$customize_file" ]] && source "$customize_file"
>   ^-- SC1090: Can't follow non-constant
> source. Use a directive to specify location.
>
>
> In - line 647:
> *)   try_ext_cmd $cmd "$@" ;;
>  ^-- SC2086: Double quote to
> prevent globbing and word splitting.
>
>
> In - line 659:
> read -e -p 'pw> ' command options
> ^-- SC2162: read without -r will mangle backslashes.
>
>
> In - line 665:
> *)   run_cmd $command $options ;;
>  ^-- SC2086: Double quote to prevent globbing and
> word splitting.
>   ^-- SC2086: Double quote to prevent
> globbing and word splitting.
>
>
> In - line 684:
> sleep $TIMEOUT
>   ^-- SC2086: Double quote to prevent globbing and word splitting.
>
>
> In - line 698:
> source "$PW_DIR/cmd_$cmd.sh"
> ^-- SC1090: Can't follow non-constant source. Use a directive to
> specify location.
>
>
> In - line 699:
> debug running: cmd_$cmd "$@"
>^-- SC2086: Double quote to prevent globbing
> and word splitting.
>
>
> In - line 700:
> cmd_$cmd "$@"
> ^-- SC2086: Double quote to prevent globbing and word
> splitting.
>
>
> In - line 707:
> source "$LIBDIR/ext/$PLATFORM/cmd_$cmd.sh"
> ^-- SC1090: Can't follow non-constant source. Use a directive to
> specify location.
>
>
> In - 

Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

On Mon, Jul 16, 2018 at 1:02 PM Chris Lamb  wrote:

> Hi Holger,
>
> > please *dont* sponsor this until Dashamir has addressed the concerns
> > pointed out in
> >
> https://lists.debian.org/msgid-search/aa2d4d3d-41d2-5399-225b-f492be2d2...@t-online.de
>
> (I've added a link to this thread on mentors.debian.net)
>

Chris (and Holger),
You could have forwarded that message to me, instead of trying to block my
application.

Dashamir


>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>

Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

On Mon, Jul 16, 2018 at 12:34 PM Holger Levsen 
wrote:

> On Mon, Jul 16, 2018 at 05:56:39AM +0200, Dashamir Hoxha wrote:
> > I just uploaded it: https://mentors.debian.net/package/pw
> > Please review and sponsor it.
>
> please *dont* sponsor this until Dashamir has addressed the concerns
> pointed out in
>
> https://lists.debian.org/msgid-search/aa2d4d3d-41d2-5399-225b-f492be2d2...@t-online.de
>
>
The email pointed out by the link has not arrived me at all.
It is not in my inbox, it is not in my Spam, it is not in my Trash.
I don't know what has happened, but I am not trying to avoid
or ignore legitimate questions or concerns.

I just figured out that I am not subscribed to debian-devel
and Carsten has not included me on the Cc:

> Hmm, do you have tried to validate your shell code?
>
> https://www.shellcheck.net/
>
> I just pasted
> https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh into
> and got quite a lot of problematic remarks.

I just tried it and most of the warnings are about using double quotes
(when I know that they are not needed) and about not being able to
follow included files.
There is only 1 potentially useful suggestion in all of them.

> Have you test cases to prevent things Philipp has raised?
> The concerns Philipp mentioned are valid, creating safe shell code isn't
> easy and writing correct syntax isn't enough.

I have the same answer that I gave to Philipp. He has not looked close
enough to the code, and has not tried to follow its logic.
For example, error *messages* of `tar` are suppressed, not the errors
themselves. The result of the command is checked afterwards.
Etc. we can discuss them later.

> Your ITP about password managing isn't the first of course, as far I can
> remember the common sense was that using Bash or any other Shell isn't
> the best choice for doing things like this.

It all depends on the skills and experience of the programmer.
Bash may be cryptic, ugly, difficult, etc. but nonetheless it is also
powerful.
Everybody claimed the same for javascript 20 years ago, but now it rules
the world.

Regards,
Dashamir


> --
> cheers,
> Holger
>

Bug#903815: ITP: pw -- A simple command-line password manager

[Philipp Kern]

Hi,

rather than trying to appeal to authority like Marc - I could have been
wrong -, I will point out that my first point was not actually addressed
at all:

++ mktemp -d /dev/shm/pw.sh.X
+ WORKDIR=/dev/shm/pw.sh.JHasAYH9zwYz1
[...]
+ decrypt /home/pkern/.pw/pw.tgz
+ local archive=/home/pkern/.pw/pw.tgz
+ local 'opts=--quiet --yes --batch '
+ [[ -z '' ]]
+ gpg2 --quiet --yes --batch --passphrase-fd 0 /home/pkern/.pw/pw.tgz.gpg
+ local err=0
+ [[ 0 -ne 0 ]]
+ tar -xzf /home/pkern/.pw/pw.tgz -C /dev/shm/pw.sh.JHasAYH9zwYz1
+ rm -f /home/pkern/.pw/pw.tgz

This clearly writes the unencrypted tarball out to disk.

Now you might say "I will fix that". But I think the behavior in this
thread was sufficient evidence to not package this in Debian. I know it
is hard to deal with criticism and I could have phrased my mail
differently, but this is clearly not the way. What if there is another
contentious bug? Will you also insult your users and your fellow
developers (no matter how senior)?

I could not have phrased it better than Simon with "let's not try to
audit scripts without `set -e`" and his other point of not using shell
scripts for non-trivial matters. Yes, it's a valid language. Yes, people
can write good scripts in it. But it is very hard and this thread has
not given me evidence that the creation process of this script mastered
it. Especially how hard it is to reason about a script that can fail
silently in all places. Especially if it's something that handles a
user's secrets.

> Whoever stops auditing this Bash application because it does not> start with 
> `set -e`, does not have the right skills and experience
for> reviewing/auditing it.
And these ad hominems are just unhelpful.

Kind regards
Philipp Kern

Bug#903815: ITP: pw -- A simple command-line password manager

[Holger Levsen]

On Sun, Jul 15, 2018 at 12:41:36PM +0200, Carsten Schoenert wrote:
> Hmm, do you have tried to validate your shell code?
> https://www.shellcheck.net/
> I just pasted
> https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh into
> and got quite a lot of problematic remarks.

I've also done this now and must say/add "ouch":

$ sudo apt install shellcheck
$ curl -s https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh | 
shellcheck -

In - line 26:
$GPG --symmetric $opts --cipher-algo=AES256 \
 ^-- SC2086: Double quote to prevent globbing and word 
splitting.


In - line 31:
$GPG --encrypt $opts --use-agent --no-encrypt-to \
   ^-- SC2086: Double quote to prevent globbing and word 
splitting.


In - line 32:
$recipients "$archive"
^-- SC2086: Double quote to prevent globbing and word splitting.


In - line 39:
$GPG $opts --passphrase-fd 0 "$archive.gpg" <<< "$PASSPHRASE"
 ^-- SC2086: Double quote to prevent globbing and word splitting.


In - line 41:
$GPG --decrypt $opts --use-agent --output="$archive" "$archive.gpg"
   ^-- SC2086: Double quote to prevent globbing and word 
splitting.


In - line 71:
make_workdir
^-- SC2119: Use make_workdir "$@" if function's $1 should mean script's $1.


In - line 91:
make_workdir
^-- SC2119: Use make_workdir "$@" if function's $1 should mean script's $1.


In - line 144:
local before="$(xclip -o -selection "$X_SELECTION" 2>/dev/null | base64)"
  ^-- SC2155: Declare and assign separately to avoid masking return 
values.


In - line 149:
local now="$(xclip -o -selection "$X_SELECTION" | base64)"
  ^-- SC2155: Declare and assign separately to avoid masking return 
values.


In - line 166:
make_workdir() {
^-- SC2120: make_workdir references arguments, but none are ever passed.


In - line 189:
find "$WORKDIR" -type f -exec $SHRED {} +
  ^-- SC2086: Double quote to prevent 
globbing and word splitting.


In - line 200:
[[ -f "$platform_file" ]] && source "$platform_file"
 ^-- SC1090: Can't follow non-constant source. Use 
a directive to specify location.


In - line 346:
local pass="$(cat "$WORKDIR/$path" | head -n 1)"
  ^-- SC2155: Declare and assign separately to avoid masking return 
values.
  ^-- SC2002: Useless cat. Consider 'cmd < file | ..' 
or 'cmd file | ..' instead.


In - line 569:
GPG_KEYS="$@"
 ^-- SC2124: Assigning an array to a string! Assign as array, or 
use * instead of @ to concatenate.


In - line 584:
$GPG $GPG_OPTS --gen-key
 ^-- SC2086: Double quote to prevent globbing and word splitting.


In - line 606:
| while read pwfile
^-- SC2162: read without -r will mangle backslashes.


In - line 624:
[[ -f "$customize_file" ]] && source "$customize_file"
  ^-- SC1090: Can't follow non-constant source. Use 
a directive to specify location.


In - line 647:
*)   try_ext_cmd $cmd "$@" ;;
 ^-- SC2086: Double quote to 
prevent globbing and word splitting.


In - line 659:
read -e -p 'pw> ' command options
^-- SC2162: read without -r will mangle backslashes.


In - line 665:
*)   run_cmd $command $options ;;
 ^-- SC2086: Double quote to prevent globbing and word 
splitting.
  ^-- SC2086: Double quote to prevent globbing 
and word splitting.


In - line 684:
sleep $TIMEOUT
  ^-- SC2086: Double quote to prevent globbing and word splitting.


In - line 698:
source "$PW_DIR/cmd_$cmd.sh"
^-- SC1090: Can't follow non-constant source. Use a directive to 
specify location.


In - line 699:
debug running: cmd_$cmd "$@"
   ^-- SC2086: Double quote to prevent globbing and 
word splitting.


In - line 700:
cmd_$cmd "$@"
^-- SC2086: Double quote to prevent globbing and word splitting.


In - line 707:
source "$LIBDIR/ext/$PLATFORM/cmd_$cmd.sh"
^-- SC1090: Can't follow non-constant source. Use a directive to 
specify location.


In - line 708:
debug running: cmd_$cmd "$@"
   ^-- SC2086: Double quote to prevent globbing and 
word splitting.


In - line 709:
cmd_$cmd "$@"
^-- SC2086: Double quote to prevent globbing and word splitting.


In - line 716:
source "$LIBDIR/ext/cmd_$cmd.sh"
^-- SC1090: Can't follow non-constant source. Use a directive to 
specify location.


In - line 717:
debug running: cmd_$cmd "$@"
   ^-- SC2086: Double quote to prevent globbing and 
word splitting.


In - line 718:
cmd_$cmd "$@"
^-- 

Bug#903815: ITP: pw -- A simple command-line password manager

[Dashamir Hoxha]

I just found this message in Spam, so I did not ignore it intentionally.

On Sun, Jul 15, 2018 at 11:47 PM Simon McVittie  wrote:

> On Sun, 15 Jul 2018 at 12:07:30 +0200, Dashamir Hoxha wrote:
> > Either you did not look close enough to the code, or you are not
> > an expert on bash scripting (bash is a bit cryptic and difficult
> > to understand even for experts).
>
> You are right to say that shell scripting (for bash or for Bourne shells
> in general) is cryptic and difficult to understand. I've found that many
> of the people who understand shell well enough to write correct shell
> scripts prefer to avoid writing non-trivial shell scripts, because they
> know they will be more productive in a language with fewer sharp edges.
>

I feel more productive with Bash scripts, maybe because I have
used them for a long time, for non-trivial things.


>
> In my experience, writing a robust shell script requires a lot of
> defensive programming (this is not just my personal opinion, Debian
> Policy also touches on this [1]).
>

I always do defensive programming, not always with bash scripting.


>
> > Instead of basing your judgment on general opinions, why don't you
> > try to find any particular situation that will break the script in some
> > interesting way ;) This is called proof by counter-example.
> > If you cannot do this, and if nobody else can do this, then you cannot
> > claim that it is not safe to use this script.
>
> You can use proof by counter-example to demonstrate that a particular
> shell script is not correct: if your assertion is "this shell script
> behaves as documented", finding an input that will make the script
> behave not-as-documented disproves that assertion. The converse is
> not true. If nobody finds an input that breaks the shell script, that
> does not mean that no such input exists: it could equally well mean
> that nobody has looked for long enough yet, for instance because they
> consider auditing a shell script that doesn't start with set -e [1]
> to be an inefficient use of their time.
>

While `set -e` could be the right thing for trivial administration scripts
(like installation, or running a bunch of commands, etc.), it would be
the wrong thing for a non-trivial application, like 'pw', because it can
leave the application in an inconsistent state. It is a poor substitution
for defensive programming.

Whoever stops auditing this Bash application because it does not
start with `set -e`, does not have the right skills and experience for
reviewing/auditing it.



>
> smcv
>
> [1] https://www.debian.org/doc/debian-policy/#scripts
>

Bug#903815: ITP: pw -- A simple command-line password manager

[Chris Lamb]

Hi Holger,

> please *dont* sponsor this until Dashamir has addressed the concerns
> pointed out in
> https://lists.debian.org/msgid-search/aa2d4d3d-41d2-5399-225b-f492be2d2...@t-online.de

(I've added a link to this thread on mentors.debian.net)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903815: ITP: pw -- A simple command-line password manager

[Holger Levsen]

On Mon, Jul 16, 2018 at 05:56:39AM +0200, Dashamir Hoxha wrote:
> I just uploaded it: https://mentors.debian.net/package/pw
> Please review and sponsor it.

please *dont* sponsor this until Dashamir has addressed the concerns
pointed out in
https://lists.debian.org/msgid-search/aa2d4d3d-41d2-5399-225b-f492be2d2...@t-online.de


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#903163: Adding OpenPGP smartcard support to LUKS

[Chris Lamb]

Dear Guilhem,

> Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the
> hook is copying private key material to the initramfs, but […]

My gut tells me we should incoropate OpenPGP support directly into
Debian's src:cryptsetup simply based on ensuring its on-going
maintainability, etc. Especially important given that, for example,
an API change or other breakage might result in an unbootable system.

Does that work for you in principle Guilhem? I'm assuming we can
"just" merge in the aforementioned package (!) and fix up some of the
issues, including the umask one you already outlined.

What would be the next steps here? :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#903884: ITP: r-cran-fansi -- GNU R ANSI control sequence aware string functions

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-fansi
  Version : 0.2.3
  Upstream Author : Brodie Gaslam,
* URL : https://cran.r-project.org/package=fansi
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R ANSI control sequence aware string functions
 This GNU R package Counterparts to R string manipulation functions
 that account for the effects of ANSI text formatting control
 sequences.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-fansi
This package is needed to update r-cran-pillar to its latest upstream version.

Bug#903883: ITP: python-django-dbconn-retry -- reconnect on a failed database

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-dbconn-retry
  Version : 0.1.5
  Upstream Author : Jonas Maurus 
* URL : https://github.com/jdelic/django-dbconn-retry/
* License : BSD-3-clause
  Programming Lang: Python
  Description : reconnect on a failed database

 This library monkeypatches django.db.backends.base.BaseDatabaseWrapper so that
 when a database operation fails because the underlying TCP connection was
 already closed, it first tried to reconnect, instead of immediately raising an
 OperationException.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAltMOpMRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoIHwf/aZ/p6LNMKsCs5WzTxx76czSgkWnbnWwL
lmgAgKNq62KXexBnHqvbmbniM1pDRhcG8u+yCMdIZUU5JHMRvHSQ7W5vC/Nwr8Ns
EW6rwBpIRlUQxW/zouX9kGk7pJ89B8JOsZgaN0hyLgjo5UbhqjPWwwS1STcrlDJJ
84dWH2bO/TMotSNnyrnPWhMb/Q9aNLYtVpowtPmQ/QkFwcK7p2+uNFh3yoNd/5yK
47jqySCuDF4vAMqI5gfUR/WIENd0wD5bRcX475WyyfzWTg2bc09f6iugqO6t6k46
G7MuiCLfPGWfPGfK+FlR4JHKADlncWZTmkTYUSbxA3uoD3Xpez9+fw==
=mVdu
-END PGP SIGNATURE-