Dear mentors,
I am looking for a sponsor for my package "pw"
* Package name : pw
Version : 1.2-1
Upstream Author : Dashamir Hoxha <dashohoxha@gmail.com>
* URL : https://github.com/dashohoxha/pw
* License : GPL-2+
Section : misc
It builds those binary packages:
pw - Simple command-line password manager.
To access further information about this package, please visit the following URL:
https://mentors.debian.net/package/pw
Alternatively, one can download the package with dget using this command:
dget -x https://mentors.debian.net/debian/pool/main/p/pw/pw_1.2-1.dsc
More information about "pw" can be obtained from the man page:
http://dashohoxha.github.io/pw/man/
Regards,
Dashamir Hoxha
Control: tags -1 + moreinfo Hello, Thank you for your interest in Debian. From the website (which unfortunately uses github): pw was written by Dashamir Hoxha (dashohoxha@gmail.com). The code is on GitHub at https://github.com/dashohoxha/pw. pw started as a fork of pass (http://www.passwordstore.org/), written by Jason A. Donenfeld (Jason@zx2c4.com). pass is already packaged, works perfectly (I use it myself), has an active upstream, and doesn't use github (which IMO is a feature nowadays). What is the advantage of having "pw" in the archive? Thanks,
Hi Dashamir, please make sure to adress the remarks in #903815. Just ignoring them and still going forward with an RFS is not going to work out. I'm sorry but unless that is sorted out, I think pw is not suitable for Debian at this point of time. (And frankly, they way you've answered on the ITP contributes to this impression.)
A couple of years ago I made some suggestions for improvement to 'pass'. I proposed to use an encrypted archive for the whole directory of passwords, instead of encrypting only the passwords, because this way the structure of the passwords is hidden and protected as well, besides the passwords themselves. This looks like a reasonable thing, however it conflicts with some other feature of 'pass', namely the ability to share different branches of passwords with different people. Since 'pass' is widely used, there is no way to remove an existing feature from it, since some of the users may already depend on it. So, my proposal could not be technically accepted and the only way was to start a fork, which I did. Later I continued to add more features which make it different from 'pass'. For example having a GPG key is a must for using 'pass', however in 'pw' it is only an option, one can also use a simple password for encrypting the archive. In my opinion this makes 'pw' easier to get started, compared to 'pass', since we all know that managing GPG keys is not an easy task, especially for beginners. Another difference is that in 'pass' you can share your passwords with other people only through a central git repository. In 'pw' you need to synchronize the encrypted archives with other people, and this can be done with 'scp' or 'rsync' or any other means. So, the main target users of 'pass' are big enterprises, or organizations, or corporations. On the other hand 'pw' is more suitable for individuals or small groups. I do not claim that 'pw' is better than 'pass', but at least they are different, because they have different features. So, it makes sense to have both of them in the repository, and let the users decide which one is more suitable for their needs. References: - https://lists.zx2c4.com/pipermail/password-store/2016-January/001887.html - https://lists.zx2c4.com/pipermail/password-store/2016-January/001902.html - https://lists.zx2c4.com/pipermail/password-store/2016-January/001928.html I don't think that the place of hosting adds or removes anything to the merits of an application. However 'pw' is a free software and it is hosted on a site that so far has offered great service, and is friendly and not hostile to free software (at least not yet). Anybody who cares about it is free to make a mirror to their preferred or trusted hosting service. I do this often for the programs or tools that I need to use on my applications, just in case that they suddenly disappear from the face of the Earth. If I had hosted 'pw' on my own personal server, this would not make it more safe, or secure, or reliable. My point is that the place of hosting does not matter.
I have not ignored any remarks. But a stupid question cannot have a cleaver answer. If you are the one who makes the final decisions on Debian, then I have no choice but to accept your decision. But my impression is that there is no central authority on Debian, and a new package proposal needs just a single sponsor in order to be accepted. So, I am just going to be patient until someone sponsors it. And meanwhile I will try to avoid any stupid questions or stupid people.
----- Forwarded message from Holger Levsen <holger@layer-acht.org> ----- Date: Mon, 16 Jul 2018 10:34:42 +0000 From: Holger Levsen <holger@layer-acht.org> To: Dashamir Hoxha <dashohoxha@gmail.com> Cc: bugs-debian@antipoul.fr, 903815@bugs.debian.org, debian-devel@lists.debian.org please *dont* sponsor this until Dashamir has addressed the concerns pointed out in https://lists.debian.org/msgid-search/aa2d4d3d-41d2-5399-225b-f492be2d2c1c@t-online.de----- End forwarded message -----
$ 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 "$@"
^-- SC2086: Double quote to prevent globbing and word splitting.
In - line 723:
cmd_get $cmd
^-- SC2086: Double quote to prevent globbing and word splitting.
In - line 753:
source "$config_file"
^-- SC1090: Can't follow non-constant source. Use a directive to specify location.
In - line 781:
[[ -f "$ARCHIVE.gpg.keys" ]] && source "$ARCHIVE.gpg.keys" # get GPG_KEYS
^-- SC1090: Can't follow non-constant source. Use a directive to specify location.
erm… Erm… You are wrong on your "impression", and I encourage you to verify your facts before sending mails to the world. *There is* an authority on the archive: that would be the ftp-masters, who can one-sidedly decide whether a package can stay in the archive. I find you attitude in this single email (as well in the others, but I read with enough attention only this one), very, *very* counterproductive (en_GB reading), and I urge you to change your tone if you plan on interacting with the project. And for you information, it's very rare that once a DD says a package is no good, a random other DD oversteps the former and goes ahead uploading it.
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,
Why would you need to remove a feature from it? Why not add a new "mode" or option? I'm not a security expert, but using a "simple password" for encrypting the archive instead of a 4096 RSA key seems like a bad thing to do, even if done in the name of "ease of use". But as I said, I'm not an expert in this area (and I confess I haven't spent too much time thinking about the implications). First of all, git is not centralized; it's companies like github that made it seem like a centralized thing. If you can use scp, then you can also clone a git repository via SSH. And as for rsync, one can easily mirror the local repository by rsync'ing the ~/.password-store/ directory. What?! I completely disagree with this statement. I don't know how you reached the conclusion that 'pass' has "big enterprises, or organizations, or corporations". I use pass myself as an individual, and I know several other *individuals* who also use it. The fact that it requires GPG is *not* an anti-feature for individuals, as you seem to imply. They're indeed different, but I feel reticent in accepting 'pw' because IMO it promotes less security, not more. philosophically. Now, this is my personal opinion, of course. However, saying that github "is friendly to free software" is pushing a little too far. github uses proprietary technologies both in the backend and in the frontend. It uses proprietary JavaScript. It promotes the mentality that git is centralized. So I find it a bit hard to say that it "is friendly to free software". Anyway, again: this e-mail is my personal position. If some other DD thinks 'pw' is a nice addition to our archives, that's fine. Cheers,
On Mon, 16 Jul 2018 15:56:04 +0200 Dashamir Hoxha <dashohoxha@gmail.com > wrote: (...) Then lets just close the bugs.
Përshëndetje, unë jam avokati Daniel M. Roland, ju kam shkruar më herët në lidhje me trashëgiminë e familjes tuaj, por ende nuk kam marrë përgjigje, pse?