Re: Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.
Hello there, let me remind you of different time zones :) Thanks for calling me. As you could see from the mailing list, I simply forked because the author and collabs weren't entirely OK on my approach of loading extensions even before handling internal commands. And that's just fine, I don't intend to force push my ideas into anyone. Once I forked, I kept developing without waiting for pass. I implemented the help from extensions, and now I'm working on a feature that enables for filename encryption to solve the metadata leak: https://github.com/HacKanCuBa/passh/projects Which is taking me a while since bash falls a bit short here (but can be handled). I'll try my best to develop this feature as an extension so it can be easily used by pass too, but it might not be possible given that it affects every operation: show, insert, edit, etc... And from the mailing list, you might see that such feature was discussed several times. I'll propose it once again as soon as I have the code working. There are some extensions that tries to solve it too, but aren't enough nor completely useful from my point of view (let me know if you require a more detailed explanation here). Regarding licensing, I usually prefer GPL3, but if, as Christian says, issues might arise that could interfere with sharing code with pass, then I would change it to GPL2.0+. Please explain me more about this. (Btw, I'm editing the readme so it reads 2.0+ instead of 2.0 as noted). I'm going to make myself some time to write a patch the way pass requires (plain in the mailing list, no attachments) to see how that goes again and satisfy inquires done in this thread. Thanks for everything so far! Cheers! On March 20, 2017 5:37:22 AM GMT-03:00, Geert Stappers wrote: >On Mon, Mar 20, 2017 at 07:21:00PM +1100, Brian May wrote: >> Christian Seiler writes: >> >> > Specifically take a look at this message from the author of the >original >> > tool: >> > >https://lists.zx2c4.com/pipermail/password-store/2017-February/002799.html >> > >> > The fork appears to have happened after that, but wasn't mentioned >at >> > all on the upstream mailing list. >> >> "However, the basic ideas seem like good ones, and I'll look into >> adopting these with a less offensive implementation." >> >> Seems like the author liked the concepts behinds the patches, but >felt >> that the patches needed more work. I think I would have started by >> trying to submit a smaller change (e.g. maybe the first patch in the >> series). > >The author of `passh`, the forker of `pass` is now also in the To: >field. > >I did add Ivan as an invite to join this discussion. >To know why the fork was needed. ( and maybe if it could be avoided ) > >Previous postings are at http://bugs.debian.org/858229 > > >> >> I don't see any response to this email. >> >> Doesn't inspire confidence :-( > >The ITP is about six hours old. >Allow people some time to response :-) > > >Groeten >Geert Stappers >-- >Leven en laten leven -- Barrera Oro, Iván A. GPG: 0x35710D312FDE468B
Re: Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.
On Mon, Mar 20, 2017 at 07:21:00PM +1100, Brian May wrote: > Christian Seiler writes: > > > Specifically take a look at this message from the author of the original > > tool: > > https://lists.zx2c4.com/pipermail/password-store/2017-February/002799.html > > > > The fork appears to have happened after that, but wasn't mentioned at > > all on the upstream mailing list. > > "However, the basic ideas seem like good ones, and I'll look into > adopting these with a less offensive implementation." > > Seems like the author liked the concepts behinds the patches, but felt > that the patches needed more work. I think I would have started by > trying to submit a smaller change (e.g. maybe the first patch in the > series). The author of `passh`, the forker of `pass` is now also in the To: field. I did add Ivan as an invite to join this discussion. To know why the fork was needed. ( and maybe if it could be avoided ) Previous postings are at http://bugs.debian.org/858229 > > I don't see any response to this email. > > Doesn't inspire confidence :-( The ITP is about six hours old. Allow people some time to response :-) Groeten Geert Stappers -- Leven en laten leven
Re: Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.
Christian Seiler writes: > Specifically take a look at this message from the author of the original > tool: > https://lists.zx2c4.com/pipermail/password-store/2017-February/002799.html > > The fork appears to have happened after that, but wasn't mentioned at > all on the upstream mailing list. "However, the basic ideas seem like good ones, and I'll look into adopting these with a less offensive implementation." Seems like the author liked the concepts behinds the patches, but felt that the patches needed more work. I think I would have started by trying to submit a smaller change (e.g. maybe the first patch in the series). I don't see any response to this email. Doesn't inspire confidence :-( -- Brian May
Re: Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.
Hi again, On 03/20/2017 07:43 AM, Christian Seiler wrote: > And while that shouldn't be part of the package description later on, > a short comment in the ITP why a fork was required would also be nice. > Did the original project just not want to merge this? What's the use > case for these changes that can't be supported by the original? I've done some digging in the mailing list for the original upstream project and found this thread: https://lists.zx2c4.com/pipermail/password-store/2017-February/thread.html#2728 Specifically take a look at this message from the author of the original tool: https://lists.zx2c4.com/pipermail/password-store/2017-February/002799.html The fork appears to have happened after that, but wasn't mentioned at all on the upstream mailing list. I haven't looked at the changes specifically, so I can't comment on the issue of code quality at all, but that a relatively new user [1] forks the entire project immediately after being shot down a bit for a patch series (where the response was maybe a bit harsh, but not entirely negative) doesn't instill me with a lot of confidence in the fork, especially since the author of the fork hasn't mentioned any specific use case why the changed functionality is needed at all, as far as I can tell. (And making --help show extensions was something that devs of the original project were interested in including regardless.) Just my 2¢. Regards, Christian [1] https://lists.zx2c4.com/pipermail/password-store/2017-January/002664.html
Re: Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.
On 03/20/2017 06:18 AM, Adrian Alves wrote: > Package: wnpp > Severity: wishlist > Owner: Adrian Alves > > * Package name: passh > Version : 1.7.1 > Upstream Author : Ivan Ariel Barrera Oro > * URL : https://github.com/HacKanCuBa/passh > * License : GPL-3 > Programming Lang: bash > Description : passh: a pass fork - stores, retrieves, generates, and > synchronizes passwords securely. > > Pass is a simple password store. This fork changes a few > things while trying to maintain most of it intact, > specially the core idea. I will keep pulling pass commits, > and also pushing my modifications to them. It would be great if you could go into a bit more detail why this fork is needed? "changes a few things" is _very_ unspecific. I've had a look at the upstream website, and found this: https://github.com/HacKanCuBa/passh#user-content-changes-from-pass-master So apparently the only real difference (apart from branding) is extension handling. This should definitely go in the package description to allow people to decide which one they'd want to install. And while that shouldn't be part of the package description later on, a short comment in the ITP why a fork was required would also be nice. Did the original project just not want to merge this? What's the use case for these changes that can't be supported by the original? Also, a minor note, unrelated to Debian packaging: the fork claims in https://github.com/HacKanCuBa/passh#license that the original is GPL-2 and that the fork is GPL-3+. If that were actually true, the fork would be a license violation. Luckily for the fork from reading the COPYING file of the original, that is is actually licensed under GPL-2+ (not just GPL-2), so forking as GPL-3+ is fine. (That said, while I generally like the GPL-3, forking a GPL-2+ project under GPL-3+ does not allow the original project to easily merge back changes made in the fork, they'd first have to get explicit permission.) Regards, Christian
