Re: Problems in the macOS Terminal app with `pass show -c some/password`?

[Kenny Evitt]

Thanks for the suggestions "yanchenko.igor" and Oliver!

Perhaps most importantly, as a general update, I haven't observed the
original behavior at all in the past few days.

I didn't see anything informative in the log file from running
`script` as suggested.

The `TERM` variable seems fine too:

```
$ echo "$TERM"
xterm-256color
```

I haven't set it anywhere and its value is, AFAIK, the initial system
default. I'm only using the macOS Terminal app as-is; neither tmux nor
anything similar.

Thanks again for your help! If I learn anything more that might be
pertinent (and potentially helpful for others), I'll reply to this
thread.

On Thu, Dec 30, 2021 at 12:45 AM yanchenko.i...@gmail.com
 wrote:
>
> I suggest to record your terminal using script:
>
> script logfile.txt
> pass show -c some/password
> exit
>
> And then check the logfile.txt, which might give you some ideas.
>
>
> On Thu, Dec 30, 2021 at 1:57 AM Kenny Evitt  wrote:
> >
> > I installed `pass` via Homebrew – version `v1.7.4`.
> >
> > I'm setting-up a new Mac (macOS 12.0.1) and I've noticed a weird
> > problem with the (macOS included) Terminal app whenever I use the
> > `pass show -c ...` command.
> >
> > It _seems_ like maybe the 'clip' program that's being used doesn't
> > work well with the (new?) version of the Terminal app – or something
> > along those lines.
> >
> > After I run `show -c` commands (which works), the "Copied ... to
> > clipboard" messages 'clobbers' the shell prompt and then further input
> > doesn't _visibly_ work – I can type and maybe (?) run commands, but
> > the command seems to be 'erased' after I run it (i.e. hit Enter) and
> > no output is visible in the shell. I'd _guess_ somehow the same 'line'
> > of the shell output/history is being repeatedly overwritten.
> >
> > Any ideas?

Problems in the macOS Terminal app with `pass show -c some/password`?

[Kenny Evitt]

I installed `pass` via Homebrew – version `v1.7.4`.

I'm setting-up a new Mac (macOS 12.0.1) and I've noticed a weird
problem with the (macOS included) Terminal app whenever I use the
`pass show -c ...` command.

It _seems_ like maybe the 'clip' program that's being used doesn't
work well with the (new?) version of the Terminal app – or something
along those lines.

After I run `show -c` commands (which works), the "Copied ... to
clipboard" messages 'clobbers' the shell prompt and then further input
doesn't _visibly_ work – I can type and maybe (?) run commands, but
the command seems to be 'erased' after I run it (i.e. hit Enter) and
no output is visible in the shell. I'd _guess_ somehow the same 'line'
of the shell output/history is being repeatedly overwritten.

Any ideas?

Re: otp in passmenu

[Kenny Evitt]

I suspect Gildásio used "demand" but meant "request". Nothing else in
their email implies that they're 'demanding' anything from Jason, the
maintainer, or anyone else.



I think it might be reasonable for people to seriously consider
forking Pass. No one's obligated to do anything. But no one's
obligated to refrain from changing Pass, or refrain from sharing those
changes either.

(I'd strongly suggest picking a new distinctive name, or at least a
distinctive variation on "pass" or "password store".)

I suspect Jason considers Pass mostly complete as-is. And that's fine!
I mostly agree with that myself. My own previous patches were never
accepted, and Jason had good reasons for doing so.

But it's frustrating not having patches accepted, or running one's own
custom private 'fork'. If people want to make changes useful to them,
and share those changes with others, then a fork could make sense.
(It's a lot of work tho!)


On Sun, Apr 11, 2021 at 10:07 AM Jonas Kalderstam
 wrote:
>
> On 9 April 2021 04:09:03 CEST, "Gildásio Júnior"  
> wrote:
> >I have the same demand as Alessandro Accardo mentioned in Sep 2018 [0].
> >He submited a patch, receive a feedback, updated it and I couldn't see
> >any other new feedback.
>
> I wouldn't expect much in terms of a reply when you have "demands" on people 
> working for free in their spare time..
>
> >PS: I didn't have experience contribut with git patches by email. So
> >please let me know if I did something wrong and how can get the right
> >path.
>
> See https://git-send-email.io for an excellent guide to git and email.
>
>

Re: curious: why use own hosting rather than github?

[Kenny Evitt]

I have no complaints about Jason's maintenance of this project. Thanks
again for your great work Jason!

Anyone is free to host the Pass repo on GitHub; I have two such 'forks':

- https://github.com/kenny-evitt/password-store
- https://github.com/kenny-evitt/password-store-buw

They're both old – the most recent commit on the 'regular' project
above is from 2016.

That second one is an explicit 'soft fork' as it contains patches
(commits) that I wasn't able to write in a way that Jason was willing
to accept. (They're for the old Bash on Ubuntu on Windows and pertain
to clipboard support in that specific not-very-Unixy environment.)

If anyone wants to use either of those repos as a community issue
tracker, they are welcome to do so. But I'm not personally committed
to helping! So, practically, it might be better to just create another
fork/project.

Armin wrote:

> However, no matter which system is being used, I believe it is important for 
> any project to provide feedback on patches and bug reports in a timely manner.

I agree that CAN be important – and is or is not to Armin or anyone
else. But no one's obligated to provide ANYTHING in a timely manner or
at all. If timely feedback is important, then you should seek to
secure it – and, ideally, without badgering or guilting someone into
providing it (for free).

One of the beauties of open source is that almost anyone can help
themselves (if they're sufficiently motivated). Anyone can create
another GitHub fork/project for Pass. I suspect the limiting resource
is the willingness of anyone to actually provide feedback for such a
GitHub project, in a timely manner or not. Having done that kind of
(unpaid) work myself in the past, I can vouch that it can be a LOT of
work and, sadly, often unsatisfying or even dispiriting. The worst
aspect to me was dealing with 'entitlement'. I often found that
_galling_.


On Mon, Nov 23, 2020 at 10:52 AM Jason A. Donenfeld  wrote:
>
> Generally I sweep the list picking up missing patches when it's time
> to make a new release. Most are skipped, because anybody can write a
> little casual bash, and so the signal-to-noise ratio is not very good.
> But releases do get made, and patches do get incorporated.
>
> Jason

Re: Windows implementation of passwordstore in pure batch

[Kenny Evitt]

I just checked the `Ubuntu` app on my Windows box and the output of `uname`
remains `Linux`.

Here are the previous threads from the archives:

 - https://lists.zx2c4.com/pipermail/password-store/2017-July/002987.html
 -
https://lists.zx2c4.com/pipermail/password-store/2017-November/003133.html
 - https://lists.zx2c4.com/pipermail/password-store/2018-January/003164.html
 - https://lists.zx2c4.com/pipermail/password-store/2018-April/003240.html

Here's a GitHub issue (for myself) for this:

 - [Get this merged upstream · Issue #2 · kenny-evitt/password-store-buw](
https://github.com/kenny-evitt/password-store-buw/issues/2)

There are two major issues still:

 1. `uname` in the Windows Ubuntu app still outputs `Linux`.
 2. There's no builtin support for arbitrary data in the Windows clipboard.
Every single possible file/data format would have to be supported
individually (AFAICT). This means only text data, already on the clipboard,
can be restored (after Pass clears a copied password from the clipboard).

For [1], it just occurred to me that maybe there's a way to just add the
Windows clipboard support to the existing `linux.sh` script.

Jason – how do you feel about that?

For [2], maybe there's a relatively simple way to just read and write the
clipboard data as generic binary data.

Jason – would you accept patches for this if this could *only* support
restoring *text* data to the Windows clipboard?

On Sat, Feb 15, 2020 at 4:35 PM Tobias Girstmair  wrote:

> (apologies, sent from a wrong/nonexistent email address before)
>
> On Sat, Feb 15, 2020 at 10:21:55PM +0100, Jason A. Donenfeld wrote:
> > I wonder if in the
> > intervening years a reliable non-kludgy detection mechanism has been
> > discovered.
>
> what about env vars? I've got XDG_SESSION_TYPE=x11 and
> XDG_SESSION_DESKTOP=i3
> (and a bunch of other XDG_* ones) on my system.
>
> according to a quick search[1], this hasn't been discussed before.
>
> [1]:
> https://duckduckgo.com/?q=site%3Alists.zx2c4.com%2Fpipermail%2Fpassword-store+%22xdg_session_type%22
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Windows implementation of passwordstore in pure batch

[Kenny Evitt]

Nice job! Windows batch is a tough language to 'use in anger'! Bash isn't
easy either, but Windows Batch is a whole 'nother level of pain-in-the-ass:

 - windows - Batch character escaping - Stack Overflow
<https://stackoverflow.com/questions/6828751/batch-character-escaping/16018942#16018942>

Pass DOES work in the Ubuntu app on Windows (formerly Bash on Ubuntu on
Windows, and several other names before that) but I couldn't implement
clipboard support *nicely*. Jason, the creator and maintainer of Pass,
didn't like the changes I came up with – they ARE ugly.

But, in case you or anyone else is interested, I maintain a 'soft fork'
with those changes on GitHub:

 - kenny-evitt/password-store-buw: Pass: The Standard Unix Password Manager
for Bash on Ubuntu on Windows
<https://github.com/kenny-evitt/password-store-buw>

On Sun, Feb 9, 2020 at 4:19 PM Miquel Lionel  wrote:

> Hello to all the password-store mailing list,
>
>   Seeing no satisfying command line alternatives for Windows on the
> passwordstore.org page, I decided to quickly put together a batch script
> that mirrors my uses of pass on unix systems.
> It behaves like pass on most of cases, my preferred thing being the clip
> switch.
> So, it supports :
> * making dirs in the password store
> * tree like display of directory and content of theses
> * inserting,deleting passwords and password directory, with or
> without prompts
> * clipping a specific line of the password file
> * PASSWORD_STORE_DIR and PASSWORD_STORE_KEY environnement
> variable, as they're the most important ones.
> * .gpgid file to indicate which key to use in case of
> PASSWORD_STORE_KEY not set
> * viewing passwords
>
> And I think that's all for the moment.
>
> There's still things to fix : can't have spaced password names, absolutely
> no security against shouldersurfing, and many other things that I didn't
> put my finger on yet.
> But it does the job for me.
>
> https://notabug.org/lilim/pass.bat
>
> Kind regards,
> --
> Miquel Lionel 
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Add support for *clip.exe* for Bash on Ubuntu on Windows

[Kenny Evitt]

Here's a new patch (that replaces the previous one) that fixes quoting in
the `write_to_clipboard` function:

---
 src/platform/linux.sh | 29 +
 1 file changed, 29 insertions(+)
 create mode 100644 src/platform/linux.sh

diff --git a/src/platform/linux.sh b/src/platform/linux.sh
new file mode 100644
index 000..ea899f2
--- /dev/null
+++ b/src/platform/linux.sh
@@ -0,0 +1,29 @@
+# This file is actually for Bash on Ubuntu on Windows!
+
+clip() {
+ local sleep_argv0="password store sleep on display $DISPLAY"
+ pkill -f "^$sleep_argv0" 2>/dev/null && sleep 0.5
+ local before="$(read_from_clipboard | base64)"
+
+write_to_clipboard "$(echo -n "$1")"
+ (
+ ( exec -a "$sleep_argv0" sleep "$CLIP_TIME" )
+ local now="$(read_from_clipboard | base64)"
+
+ [[ $now != $(echo "$1" | base64) ]] && before="$now"
+write_to_clipboard "$(echo "$before" | base64 -d)"
+ ) 2>/dev/null & disown
+ echo "Copied $2 to clipboard. Will clear in $CLIP_TIME seconds."
+}
+
+read_from_clipboard() {
+local
text="$(/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
-Command "Add-Type -AssemblyName System.Windows.Forms;
[System.Windows.Forms.Clipboard]::GetText()")"
+# Remove trailing carriage return:
+echo "${text:0:-1}"
+}
+
+write_to_clipboard() {
+# Escape for PowerShell:
+local text="${1//\'/\'\'}"
+/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe -Command
"Add-Type -AssemblyName System.Windows.Forms;
[System.Windows.Forms.Clipboard]::SetText('$text')"
+}
-- 
2.10.0.windows.1


On Thu, Apr 5, 2018 at 10:47 AM, Kenny Evitt <kenny.ev...@gmail.com> wrote:

> I didn't submit a patch because I don't expect it be to merged upstream
> anytime soon. The 'soft fork' is just a convenient place for me to keep the
> changes where I, and anyone else, can access them.
>
> Here's the patch for the changes (excluding my "soft fork" README changes):
>
> ---
>  src/platform/linux.sh | 27 +++
>  1 file changed, 27 insertions(+)
>  create mode 100644 src/platform/linux.sh
>
> diff --git a/src/platform/linux.sh b/src/platform/linux.sh
> new file mode 100644
> index 000..93c568e
> --- /dev/null
> +++ b/src/platform/linux.sh
> @@ -0,0 +1,27 @@
> +# This file is actually for Bash on Ubuntu on Windows!
> +
> +clip() {
> + local sleep_argv0="password store sleep on display $DISPLAY"
> + pkill -f "^$sleep_argv0" 2>/dev/null && sleep 0.5
> + local before="$(read_from_clipboard | base64)"
> +
> +write_to_clipboard "$(echo -n "$1")"
> + (
> + ( exec -a "$sleep_argv0" sleep "$CLIP_TIME" )
> + local now="$(read_from_clipboard | base64)"
> +
> + [[ $now != $(echo "$1" | base64) ]] && before="$now"
> +write_to_clipboard "$(echo "$before" | base64 -d)"
> + ) 2>/dev/null & disown
> + echo "Copied $2 to clipboard. Will clear in $CLIP_TIME seconds."
> +}
> +
> +read_from_clipboard() {
> +local 
> text="$(/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
> -Command "Add-Type -AssemblyName System.Windows.Forms;
> [System.Windows.Forms.Clipboard]::GetText()")"
> +# Remove trailing carriage return:
> +echo "${text:0:-1}"
> +}
> +
> +write_to_clipboard() {
> +/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
> -Command "Add-Type -AssemblyName System.Windows.Forms;
> [System.Windows.Forms.Clipboard]::SetText(\"$1\")"
> +}
> --
> 2.10.0.windows.1
>
>
> On Wed, Apr 4, 2018 at 11:14 AM, Jason A. Donenfeld <ja...@zx2c4.com>
> wrote:
>
>> Instead of a "soft fork", why not just submit proper patches to the
>> mailing list to be reviewed and merged upstream? git-send-email is
>> your friend.
>>
>
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Add support for *clip.exe* for Bash on Ubuntu on Windows

[Kenny Evitt]

I've finished clipboard support for Bash on Ubuntu on Windows (BUW).

For now, I've setup a Git repo on GitHub with the changes –
kenny-evitt/password-store-buw:
Pass: The Standard Unix Password Manager for Bash on Ubuntu on Windows
<https://github.com/kenny-evitt/password-store-buw>

I still don't have any great ideas for the `uname` problem so the platform
file for BUW is currently named *linux.sh*.

On Thu, Jan 4, 2018 at 9:57 AM, Kenny Evitt <kenny.ev...@gmail.com> wrote:

> Hi Jason,
>
> Happy New Year!
>
> I'd like to continue working on adding clipboard support for Bash on
> Ubuntu on Windows (BUW).
>
> I've got a working platform file that can both read from and write to the
> clipboard. However, only text can be read and written. There's no way to
> handle arbitrary data (e.g. an image file) on the clipboard on Windows. Is
> that an issue?
>
> I haven't thought of or run across any nice workarounds for the problem of
> `uname` outputting "Linux" on BUW. Any thoughts?
>
> Thanks,
> Kenny
>
> On Wed, Nov 22, 2017 at 1:10 PM, Kenny Evitt <kenny.ev...@gmail.com>
> wrote:
>
>> Hi Jason,
>>
>> I finally had some time to work on this. I made some good progress
>> initially – reading from and writing to the clipboard is easy and works
>> (based on my very limited testing so far).
>>
>> However, I've run into the *effective* impossibility of being able to
>> reading, and saving, arbitrary data from the Windows clipboard. Other
>> software that does this actually *doesn't* do it – not in full generality.
>> For example, AutoHotkey, a popular Windows scripting tool, seems to support
>> specific formats and also *not *support other specific formats.
>>
>> Just based on this basic failure, I started wondering about the
>> convention that Pass follows of even bothering to save the contents of the
>> clipboard before writing data to it. What's the source of that convention?
>> Why did you adopt it for Pass? Almost all other programs seem to just
>> overwrite any existing data – why does Pass try to retain the original
>> contents?
>>
>> I looked into the Cygwin */dev/clipboard* device and, probably more
>> importantly, tested it myself with clipboard data that I wasn't (easily)
>> able to save either – a JPG copied from the Google Chrome browser. Cygwin's
>> clipboard doesn't contain any data for the image!
>>
>> So, given all of the above, is it sufficient that I can (easily) save and
>> restore *text* in the Windows clipboard? Or do we want to aim for all data?
>>
>> Have you thought about how to handle the Ubuntu-on-Windows-reports-that
>> -it-is-a-version-of-Linux-and-one-from-the-future-too problem? For now,
>> for me just testing possible approaches, I'm working with a *linux.sh*
>> platform file.
>>
>> Thanks,
>> Kenny
>>
>> On Wed, Jul 26, 2017 at 10:41 AM, Jason A. Donenfeld <ja...@zx2c4.com>
>> wrote:
>>
>>> Hi Kenny,
>>>
>>> Thanks for your response.
>>>
>>> > uname -r: 4.4.0-43-Microsoft
>>> > uname -v: #1-Microsoft Wed Dec 31 14:42:53 PST 2014
>>>
>>> Microsoft has evidently built a time machine and made a 4.4.0 before
>>> 4.4.0 existed! Surely if they can travel back in time, they can travel
>>> into the future too. In that case, I will stop working on this, and
>>> instead simply wait for them to bring pass compatibility back from a
>>> future timeline in which I actually do do the work. Wait, paradox.
>>>
>>> > uname -r: 4.4.0-43-Microsoft
>>>
>>> So this is really unfortunate. It means the only way we have of
>>> detecting WSL is by grepping uname -r. That seems like it won't mix
>>> nicely with the current strategy of source "$(uname)...". I'm a bit
>>> hesitant to bloat pass (even more) with non-standard Microsoft hacks,
>>> especially since Windows isn't free software, but I'll see if I can
>>> find a solution. If you have any suggestions, I'd be happy to hear
>>> them.
>>>
>>> > There's a (mildly disgusting) way to shove everything into the platform
>>> > file. PowerShell is installed by default on all versions of Windows
>>> since
>>> > Windows 7 and Windows Server 2008 R2 (both released at the end of
>>> 2009).
>>> > Given that WSL is new for Windows 10, it sure seems like supporting WSL
>>> > should imply we can safely expect PowerShell to be installed and
>>> available.
>>>
>>> Great, sounds like a plan then,
>>>
>>> Regards,
>>> Jason
>>>
>>
>>
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: question on security

[Kenny Evitt]

Exposing your password files shouldn't be any worse than, e.g. exposing the
same number of encrypted emails.

I do agree that it would be nice to not expose the Pass repo file names.
There are several ways to do this.

There's a Pass extension that will 'entomb' your entire repo, i.e. encrypt
the entire repo directory tree. Tho that isn't support for the Pass for iOS
app.

Another solution – one I use – is to use a Git remote helper that encrypts
the entire remote repo (including commit history and the Git internal
objects). I opened an issue for the Pass for iOS app to add support for
that remote helper  (tho
it's currently unlikely to be added anytime soon).

Currently, I just rely on the security of the private repo host I'm using
to prevent exposing directory and file names. That's probably fine.

On Sun, Jan 28, 2018 at 5:06 AM, Ben Oliver  wrote:

> On 18-01-28 10:25:31, Greg Minshall wrote:
>
>> hi.  thanks very much to the responsible parties for password-store,
>> which i'm happily using on lubuntu.
>>
>> i'm attracted to somehow synchronizing with my iphone.  the solution
>> (that i've seen) uses git for synchronizing.
>>
>> this tickles something that's worried me a bit since i started looking
>> at pass, which is, i *worry* that the security of exposing lots of tiny,
>> "known-format" (more or less) files, all encrypted with the same key,
>> may be less secure than exposing one large, known-format, file,
>> encrypted with that same key.
>>
>> (this is my intuition speaking to me and, of course, *my* intuition,
>> especially w.r.t. security, is infallible... :)
>>
>> does anyone have any opinions/numbers/facts?
>>
>> cheers, Greg
>>
>
> This is one of the main 'weaknesses' with pass - it exposes all of the
> file names and therefore (for most people I presume) website names.  There
> are ways around this but I'm not sure they work on iPhone.
>
> It's a risk I'm willing to take if the tradeoff is the excellent usability
> and simple, transparent mechanism pass uses to encrypt and send files.
>
> One thing I like about using gpg as a solution is that you can encrypt
> with multiple keys. This means you don't need to use the same key on your
> phone as on your PC.
>
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Add support for *clip.exe* for Bash on Ubuntu on Windows

[Kenny Evitt]

Hi Jason,

Happy New Year!

I'd like to continue working on adding clipboard support for Bash on Ubuntu
on Windows (BUW).

I've got a working platform file that can both read from and write to the
clipboard. However, only text can be read and written. There's no way to
handle arbitrary data (e.g. an image file) on the clipboard on Windows. Is
that an issue?

I haven't thought of or run across any nice workarounds for the problem of
`uname` outputting "Linux" on BUW. Any thoughts?

Thanks,
Kenny

On Wed, Nov 22, 2017 at 1:10 PM, Kenny Evitt <kenny.ev...@gmail.com> wrote:

> Hi Jason,
>
> I finally had some time to work on this. I made some good progress
> initially – reading from and writing to the clipboard is easy and works
> (based on my very limited testing so far).
>
> However, I've run into the *effective* impossibility of being able to
> reading, and saving, arbitrary data from the Windows clipboard. Other
> software that does this actually *doesn't* do it – not in full generality.
> For example, AutoHotkey, a popular Windows scripting tool, seems to support
> specific formats and also *not *support other specific formats.
>
> Just based on this basic failure, I started wondering about the convention
> that Pass follows of even bothering to save the contents of the clipboard
> before writing data to it. What's the source of that convention? Why did
> you adopt it for Pass? Almost all other programs seem to just overwrite any
> existing data – why does Pass try to retain the original contents?
>
> I looked into the Cygwin */dev/clipboard* device and, probably more
> importantly, tested it myself with clipboard data that I wasn't (easily)
> able to save either – a JPG copied from the Google Chrome browser. Cygwin's
> clipboard doesn't contain any data for the image!
>
> So, given all of the above, is it sufficient that I can (easily) save and
> restore *text* in the Windows clipboard? Or do we want to aim for all data?
>
> Have you thought about how to handle the Ubuntu-on-Windows-reports-
> that-it-is-a-version-of-Linux-and-one-from-the-future-too problem? For
> now, for me just testing possible approaches, I'm working with a *linux.sh*
> platform file.
>
> Thanks,
> Kenny
>
> On Wed, Jul 26, 2017 at 10:41 AM, Jason A. Donenfeld <ja...@zx2c4.com>
> wrote:
>
>> Hi Kenny,
>>
>> Thanks for your response.
>>
>> > uname -r: 4.4.0-43-Microsoft
>> > uname -v: #1-Microsoft Wed Dec 31 14:42:53 PST 2014
>>
>> Microsoft has evidently built a time machine and made a 4.4.0 before
>> 4.4.0 existed! Surely if they can travel back in time, they can travel
>> into the future too. In that case, I will stop working on this, and
>> instead simply wait for them to bring pass compatibility back from a
>> future timeline in which I actually do do the work. Wait, paradox.
>>
>> > uname -r: 4.4.0-43-Microsoft
>>
>> So this is really unfortunate. It means the only way we have of
>> detecting WSL is by grepping uname -r. That seems like it won't mix
>> nicely with the current strategy of source "$(uname)...". I'm a bit
>> hesitant to bloat pass (even more) with non-standard Microsoft hacks,
>> especially since Windows isn't free software, but I'll see if I can
>> find a solution. If you have any suggestions, I'd be happy to hear
>> them.
>>
>> > There's a (mildly disgusting) way to shove everything into the platform
>> > file. PowerShell is installed by default on all versions of Windows
>> since
>> > Windows 7 and Windows Server 2008 R2 (both released at the end of 2009).
>> > Given that WSL is new for Windows 10, it sure seems like supporting WSL
>> > should imply we can safely expect PowerShell to be installed and
>> available.
>>
>> Great, sounds like a plan then,
>>
>> Regards,
>> Jason
>>
>
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Add support for *clip.exe* for Bash on Ubuntu on Windows

[Kenny Evitt]

Hi Jason,

I finally had some time to work on this. I made some good progress
initially – reading from and writing to the clipboard is easy and works
(based on my very limited testing so far).

However, I've run into the *effective* impossibility of being able to
reading, and saving, arbitrary data from the Windows clipboard. Other
software that does this actually *doesn't* do it – not in full generality.
For example, AutoHotkey, a popular Windows scripting tool, seems to support
specific formats and also *not *support other specific formats.

Just based on this basic failure, I started wondering about the convention
that Pass follows of even bothering to save the contents of the clipboard
before writing data to it. What's the source of that convention? Why did
you adopt it for Pass? Almost all other programs seem to just overwrite any
existing data – why does Pass try to retain the original contents?

I looked into the Cygwin */dev/clipboard* device and, probably more
importantly, tested it myself with clipboard data that I wasn't (easily)
able to save either – a JPG copied from the Google Chrome browser. Cygwin's
clipboard doesn't contain any data for the image!

So, given all of the above, is it sufficient that I can (easily) save and
restore *text* in the Windows clipboard? Or do we want to aim for all data?

Have you thought about how to handle the
Ubuntu-on-Windows-reports-that-it-is-a-version-of-Linux-and-one-from-the-future-too
problem? For now, for me just testing possible approaches, I'm working with
a *linux.sh* platform file.

Thanks,
Kenny

On Wed, Jul 26, 2017 at 10:41 AM, Jason A. Donenfeld 
wrote:

> Hi Kenny,
>
> Thanks for your response.
>
> > uname -r: 4.4.0-43-Microsoft
> > uname -v: #1-Microsoft Wed Dec 31 14:42:53 PST 2014
>
> Microsoft has evidently built a time machine and made a 4.4.0 before
> 4.4.0 existed! Surely if they can travel back in time, they can travel
> into the future too. In that case, I will stop working on this, and
> instead simply wait for them to bring pass compatibility back from a
> future timeline in which I actually do do the work. Wait, paradox.
>
> > uname -r: 4.4.0-43-Microsoft
>
> So this is really unfortunate. It means the only way we have of
> detecting WSL is by grepping uname -r. That seems like it won't mix
> nicely with the current strategy of source "$(uname)...". I'm a bit
> hesitant to bloat pass (even more) with non-standard Microsoft hacks,
> especially since Windows isn't free software, but I'll see if I can
> find a solution. If you have any suggestions, I'd be happy to hear
> them.
>
> > There's a (mildly disgusting) way to shove everything into the platform
> > file. PowerShell is installed by default on all versions of Windows since
> > Windows 7 and Windows Server 2008 R2 (both released at the end of 2009).
> > Given that WSL is new for Windows 10, it sure seems like supporting WSL
> > should imply we can safely expect PowerShell to be installed and
> available.
>
> Great, sounds like a plan then,
>
> Regards,
> Jason
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Feature request: Enable use of ZFS datasets and optionally GELI

[Kenny Evitt]

(Don't forget to 'reply all' to keep the thread on the list.)

Those links don't work for me. But I was able to get at least a sense of
what `geli` and `ggatel` are based on some cursory review of Google search
results for those terms. Basically, FreeBSD can encrypt arbitrary
filesystems.

I can't think of what support Pass could have that would be relevant to
these features. What specifically do you want to do with Pass and these
features that you can't currently?

First, being only available on FreeBSD seems pretty limiting. Why would
Pass add features only available on one platform?

Second, why would you want to combine those features with Pass? Or are you
requesting that Pass be modified to (optionally?) make use of the FreeBSD
filesystem encryption features *instead* of using GPG (and any other
extensions available)?

I don't speak for the author and maintainer, but I'd guess this would make
more sense as a Pass-like or Pass-inspired project.

Pass repos are just directories with GPG-encrypted files. (There's some
conventions about what keys should be used to encrypt which files based on
*.gpg-id* files in the root directory or sub-directories.) They can also be
a Git repo for tracking changes. But besides that they're (perfectly?)
independent of any specific filesystem. Would adding support for the
FreeBSD GEOM features change that?

On Mon, Nov 20, 2017 at 8:15 AM, Daniel Jensen <debd...@gmail.com> wrote:

> Well, it’s a feature that’ll pretty much only work on FreeBSD since it
> requires GEOM.
>
> GEOM ELI (https://man.freebsd.org/geli(8)) and GGATEL (
> https://man.freebsd.org/ggatel(8)) can be used to mount a disk image as a
> directory, which is where pass stores its data structure.
>
>
>
> On 20 Nov 2017, at 14.09, Kenny Evitt <kenny.ev...@gmail.com> wrote:
>
> I'm using ZFS on some servers, but not with Pass. What kind of features
> would you want to add to Pass related to ZFS or ZFS datasets?
>
> What's GELI?
>
> Depending on what it is exactly that you want, it could probably be
> implemented as a Pass extension. I'm pretty skeptical that these features,
> whatever they are, would be sensibly added to Pass itself.
>
> On Sun, Nov 19, 2017 at 12:22 PM D. Ebdrup <debd...@gmail.com> wrote:
>
>> ZFS datasets and GELI are really powerful things and would be a great
>>
>> addition to password-store, so I’m wondering if it’s possible to
>>
>> implement this.
>>
>>
>>
>>
>>
>> Alternative, if it’s something I can figure out to do, or find someone
>>
>> with the skill to add it, is it a feature that would be accepted?
>>
>>
>> ___
>>
>> Password-Store mailing list
>>
>> Password-Store@lists.zx2c4.com
>>
>> https://lists.zx2c4.com/mailman/listinfo/password-store
>>
>>
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Feature request: Enable use of ZFS datasets and optionally GELI

[Kenny Evitt]

I'm using ZFS on some servers, but not with Pass. What kind of features
would you want to add to Pass related to ZFS or ZFS datasets?

What's GELI?

Depending on what it is exactly that you want, it could probably be
implemented as a Pass extension. I'm pretty skeptical that these features,
whatever they are, would be sensibly added to Pass itself.

On Sun, Nov 19, 2017 at 12:22 PM D. Ebdrup  wrote:

> ZFS datasets and GELI are really powerful things and would be a great
>
> addition to password-store, so I’m wondering if it’s possible to
>
> implement this.
>
>
>
>
>
> Alternative, if it’s something I can figure out to do, or find someone
>
> with the skill to add it, is it a feature that would be accepted?
>
>
> ___
>
> Password-Store mailing list
>
> Password-Store@lists.zx2c4.com
>
> https://lists.zx2c4.com/mailman/listinfo/password-store
>
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Add support for *clip.exe* for Bash on Ubuntu on Windows

[Kenny Evitt]

Here's the output of the command you asked me to run:

```
kenny@KEVITT-P3620:~$ for i in a s n r v m p i o; do echo -n "uname -$i: ";
uname -$i; done
uname -a: Linux KEVITT-P3620 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31
14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
uname -s: Linux
uname -n: KEVITT-P3620
uname -r: 4.4.0-43-Microsoft
uname -v: #1-Microsoft Wed Dec 31 14:42:53 PST 2014
uname -m: x86_64
uname -p: x86_64
uname -i: x86_64
uname -o: GNU/Linux
```

There's a (mildly disgusting) way to shove everything into the platform
file. PowerShell is installed by default on all versions of Windows since
Windows 7 and Windows Server 2008 R2 (both released at the end of 2009).
Given that WSL is new for Windows 10, it sure seems like supporting WSL
should imply we can safely expect PowerShell to be installed and available.


On Tue, Jul 25, 2017 at 11:52 AM, Jason A. Donenfeld <ja...@zx2c4.com>
wrote:

> On Tue, Jul 25, 2017 at 4:00 PM, Kenny Evitt <kenny.ev...@gmail.com>
> wrote:
> > I just looked at this briefly and I've run into a couple of problems:
> >
> >  1. `uname` in Bash on Ubuntu on Windows (BUW) outputs `Linux`, so I'd
> have
> > to name the platform file *linux.sh* or change the code in
> > *password-store.sh* that sources those files.
>
> Can you send me the output of this on WSL:
>
> for i in a s n r v m p i o; do echo -n "uname -$i: "; uname -$i; done
>
> >  2. `clip.exe` is unidirectional, i.e. there's no way for it to output
> the
> > contents of the clipboard; nor is there a standard program for doing that
> > either.
> >
> > Thoughts? Feelings?
> >
> > The Windows clipboard *can* be accessed from BUW via PowerShell – are you
> > open to that as a dependency on Windows?
>
> I don't want to introduce extra dependencies that aren't already
> included with Windows or with WSL, but if there's some disgusting way
> of shoving everything we need into the platform file, that'd be okay
> with me.
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: Add support for *clip.exe* for Bash on Ubuntu on Windows

[Kenny Evitt]

I just looked at this briefly and I've run into a couple of problems:

 1. `uname` in Bash on Ubuntu on Windows (BUW) outputs `Linux`, so I'd have
to name the platform file *linux.sh* or change the code in
*password-store.sh* that sources those files.
 2. `clip.exe` is unidirectional, i.e. there's no way for it to output the
contents of the clipboard; nor is there a standard program for doing that
either.

Thoughts? Feelings?

The Windows clipboard *can* be accessed from BUW via PowerShell – are you
open to that as a dependency on Windows?

On Mon, Jul 24, 2017 at 10:57 AM, Jason A. Donenfeld 
wrote:

> Thanks for sending this suggestion is. I'd certainly be open to
> implementing this in the form of a platform file, like we currently do
> for cygwin (depreciated now, I guess), bsd, osx, and so forth.
>
> Would you like to submit a patch?
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Add support for *clip.exe* for Bash on Ubuntu on Windows

[Kenny Evitt]

The best password manager is a little bit easier to use on Windows now
under Bash on Ubuntu on Windows – except copying to the clipboard.

`xclip` can be made to work, if you install an X Window server. Microsoft
has supplied a `clip.exe` command to copy to the clipboard so it would be
great if Pass could use that.

I would be glad to help test this and I might even be able to find a little
bit of time to work on it myself too.
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/password-store

Re: [pass] Multiple password contexts

[Kenny Evitt]

Here's my hack solution:

I have a script, somewhere in my path, and I've named it
*pass-switch-repo.bash*. Here's its contents:

```
#!/usr/bin/env bash

# This script needs to be sourced to affect the user's environment.

repo_name=$1

if [[ -z "$repo_name" ]]; then
echo "Error: No repo name was specified."
return 1
fi

repo_path="$HOME/.password-store/$repo_name"

if [[ ! -d "$repo_path" ]]; then
echo "Error: No Pass sub-directory with the name '$repo_name' exists."
return 1
fi

export PASSWORD_STORE_GIT="$repo_path"
export PASSWORD_STORE_DIR="$repo_path"

echo "Switched to repo '$repo_name'!"
```

Because it's modifying environment variables, you have to source it, e.g.:

`. pass-switch-repo.bash name-of-a-pass-context`

Bash and Git completion work just as with a regular Pass password store
("repo" per my script).

The script assumes you've organized your 'contexts' as sub-directories of
the default password store directory.

On Tue, Nov 15, 2016 at 8:52 PM, Andrew Dunn 
wrote:

> Adam:
>
> Interesting suggestion! However, it appears that it might break the
> git completion when you do that... or maybe I set something up wrong?
>
> On Mon, Nov 14, 2016 at 7:44 PM, Adam Liter  wrote:
> > You can also set up autocompletion for these aliases, e.g.:
> >
> > -
> >
> > # ~/.bashrc
> >
> > alias p1="PASSWORD_STORE_DIR=~/p1 pass"
> > alias p2="PASSWORD_STORE_DIR=~/p2 pass"
> >
> > source /usr/local/etc/bash_completion.d/password-store
> >
> > _p1(){
> > PASSWORD_STORE_DIR=~/p1 _pass
> > }
> >
> > complete -o filenames -o nospace -F _p1 p1
> >
> > _p2(){
> > PASSWORD_STORE_DIR=~/p2 _pass
> > }
> >
> > complete -o filenames -o nospace -F _p2 p2
> >
> > -
> >
> > Hope this helps!
> >
> > -Adam
> >
> > On 14 Nov 2016, at 10:14, Lenz Weber wrote:
> >
> >> something along the lines of
> >>
> >> alias p1="PASSWORD_STORE_DIR=~/p1 pass"
> >> alias p2="PASSWORD_STORE_DIR=~/p2 pass"
> >>
> >> would allow you to call p1 and p2 for the two folders respectively.
> >>
> >> On 11/14/2016 04:08 PM, Andrew Dunn wrote:
> >>> But that's the fastest way, to modify an envar? I see qtpass seems to
> >>> have a tab for multiple stores, I was just hoping to stick with cli.
> >>>
> >>> On Mon, Nov 14, 2016 at 10:07 AM, Lenz Weber  wrote:
>  just set the PASSWORD_STORE_DIR environment variable before calling
> pass.
> 
> 
>  On 11/14/2016 04:00 PM, Andrew Dunn wrote:
> > I might have completely missed this in documentation, but is it
> > possible to have multiple password roots? I'm currently managing this
> > with some bash aliases that remove/re-symlink to different
> > repositories. My use case is that I have multiple contexts for
> sharing
> > passwords with others.
> > ___
> > Password-Store mailing list
> > Password-Store@lists.zx2c4.com
> > http://lists.zx2c4.com/mailman/listinfo/password-store
> >>
> >> ___
> >> Password-Store mailing list
> >> Password-Store@lists.zx2c4.com
> >> http://lists.zx2c4.com/mailman/listinfo/password-store
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store

Re: [pass] ***UNCHECKED*** Re: [Feature Request] Add a `--raw` option to `pass ls`

[Kenny Evitt]

Alternatively, Pass could simply commit to its current implementation of
using the filesystem as it does and that would resolve any potential future
incompatibility issues just as well. If we were voting, that's what I would
vote for.

The Pass website  currently seems to
support such an interpretation:

> Password management should be simple and follow Unix philosophy
. With pass, each password
lives inside of a gpg encrypted file whose filename is the title of the
website or resource that requires the password. These encrypted files may
be organized into meaningful folder hierarchies, copied from computer to
computer, and, in general, manipulated using standard command line file
management utilities.

Every program that uses the filesystem doesn't need to provide an API with
its own abstraction over the filesystem. Anything that wants to can just
use the filesystem directly!



Even assuming that the existing patches are complete and without bugs,
there's documentation too both in Pass itself, the Pass man page, and the
Pass website, all of which might need or warrant being updated. But then of
course there's the cost of maintaining that feature indefinitely too.
Please be considerate in *expecting *someone else to commit to doing that
work for you. I'm not claiming you are, but you certainly seem to be
minimizing the amount of potential work that needs to be done.

If we're properly accounting for all of the effort involved by everyone
anywhere, the easiest thing for you to do would be to just maintain your
own private fork of Pass with whatever patches you want to incorporate. I'm
considering doing that myself precisely because writing long commands or
maintaining separate scripts is a 'hassle'. Tho of course maintaining a
fork is a 'hassle' too. Trade-offs abound!

On Thu, Nov 10, 2016 at 2:45 AM, Linden Krouse  wrote:

> While you could read the password directory directly, wouldn't it be
> better for future compatibly to have pass print the raw key names? If pass
> ever changes the way it stores it's passwords, every script relying on the
> current layout will break. Also, `{ cd 
> ${PASSWORD_STORE_DIR:-$HOME/.password-store};
> find -type f -name '*.gpg' -printf "%P\n" | sed 's/\.gpg$//'; }` is much
> longer and more difficult to read than `pass ls --raw` which
> describes exactly what is being done. Having to do this repeatedly, or
> create and store a script specifically to do this just adds more hassle to
> pass.
>
> Lastly, at least one other person has written a patch to add this feature
> so it wouldn't take any additional effort to implement, as the work as
> already been done.
>
> On Wed, Nov 9, 2016 at 3:43 PM, Lenz Weber  wrote:
>
>> Actually, if you want to write a software to use that ouput this should
>> be quite intuitive for you, yes.
>>
>> Even simpler would be
>>
>> { cd ${PASSWORD_STORE_DIR:-$HOME/.password-store}; find -type f -name
>> '*.gpg' -printf "%P\n" | sed 's/\.gpg$//'; }
>>
>> just don't forget the braces.
>>
>> Am 09.11.2016 um 21:22 schrieb Tobias Girstmair:
>> >> TL;DR We don't need `pass ls --raw` because we have `ls -1`
>> >
>> > well, `ls -1` doesn't exactly provide a recursive output. this could be
>> done with a convoluted tree statement (see my patch) or this find one
>> (which isn't simpler, and I haven't checked for symlinks or other strange
>> things):
>> >
>> >
>> > find ${PASSWORD_STORE_DIR:-$HOME/.password-store} -type f -name
>> '*.gpg'|sed 's|^${PASSWORD_STORE_DIR:-$HOME/.password-store}/||'|sed
>> 's/\.gpg$//'
>> >
>> >
>> > intuitive, isn't it? ;-)
>> >
>> > Another use case is an interactive user, who wants to copy-paste a line
>> of the `pass ls` output into `pass show`.
>> >
>> > -- Tobias
>> > ___
>> > Password-Store mailing list
>> > Password-Store@lists.zx2c4.com
>> > http://lists.zx2c4.com/mailman/listinfo/password-store
>>
>>
>>
>> ___
>> Password-Store mailing list
>> Password-Store@lists.zx2c4.com
>> http://lists.zx2c4.com/mailman/listinfo/password-store
>>
>
>
>
> --
> - Sent from my microwave oven
>
> ___
> Password-Store mailing list
> Password-Store@lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store
>
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store

[pass] Feature request – combined insert/generate/edit for new entries

[Kenny Evitt]

Jason, hooks would be fantastic. I hacked together scripts to backup and
restore my password stores as encrypted tarballs and I was going to look
into how best create backups automatically (e.g. when an entry was added,
edited, or removed). Hooks seems much better than maintaining a patched
Pass.

On Monday, July 18, 2016, Jason A. Donenfeld > wrote:

> I'll see about adding something like this to the next version of pass.
> Seems to be somewhat useful.
>
> Alternatively, I'm investigating a "hooks" framework, so that pass
> would be extensible by people wanting to do different things.
>
> Sit tight.
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store

Re: [pass] Feature request – combined insert/generate/edit for new entries

[Kenny Evitt]

Adrian, adding an `--edit` (`-e`) option to `pass generate` is exactly what
I ended up thinking was best. Thanks for the patch!

On Monday, July 18, 2016, Brian Candler  wrote:

> On 18/07/2016 08:53, Adrián López Tejedor wrote:
>
>> I sent this path the 17 of June with exactly that.
>>
>> I have added the "--edit" option to generate.
>>
>
> Excellent, thank you. I have applied this by hand.
>
> Note: I intentionally don't use a gpg agent, and I notice with "pass
> generate --edit" I get prompted for the passphrase twice - once after the
> generation has displayed the new password before entering the editor, and
> once after the editor. But I can live with this.
>
> The other thing is that when --edit is specified I think it's not
> necessary to display the newly-generated password to stdout: but as long as
> you remember to clear your scrollback buffer afterwards, that's OK too.
>
> Regards,
>
> Brian.
>
>
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store

[pass] Feature request – combined insert/generate/edit for new entries

[Kenny Evitt]

I often want to add an entry but also generate a new random password and
add additional info ('edit') and, given that I'm tracking the history of my
entries with Git, it'd be nice (or nicest) to do all of that as a single
commit. Besides the Git history, it'd also be nice to do all of that as a
single `pass ...` command too.

The closest I can come to this is to run `pass edit ...`. In my editor
(Vim) I can insert the output of running `pwgen` easily enough (by running
the Vim command `:r !pwgen -s -y 32` or similar), but it'd be nice for
`pass edit ...` to insert a password for me (if no existing entry matches
the path I provide) or for another command to do so instead of `edit`.
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store

[pass] I'd like to contribute another migration/import script for pwSafe

[Kenny Evitt]

The existing script for pwSafe seems to cover a version older than what I'm
running, version "4.9 (4900)" on Mac OS X.

I adapted the existing script to work with the tab-delimited file output by
the export feature of the version I'm running.

Here's a GitHub repo with my script:

https://github.com/kenny-evitt/pwsafe-to-pass
___
Password-Store mailing list
Password-Store@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/password-store