Re: CVS commit: pkgsrc/security/password-store

[Leonardo Taccari <leot%NetBSD.org@localhost>]

"Leonardo Taccari" writes:
> Log Message:
> password-store: Adjust BASE64 definition as part of fixsh SUBST class
>
> Instead of using a generic `base64' initialize the BASE64 variable in order to
> actually use converters/base64 (this was problematic when for example NetBSD
> base64(1) was used).
>
> Bump PKGREVISION

Sorry for not sharing more details but I have debugged it properly
only now!

The actual error was, e.g. for `pass show':

 [... `pass add foo' was done, using `bar' as password ...]
 % pass show foo
 bar
 base64: Decoding failed: Inappropriate file type or format

Tracing it via `bash -x' lead to:

 + pass=YmFyCg==
 + echo YmFyCg==
 + /usr/bin/base64 -d

...and the corresponding code path exercised is:

   365          if [[ -f $passfile ]]; then
   366                  if [[ $clip -eq 0 && $qrcode -eq 0 ]]; then
   367                          pass="$($GPG -d "${GPG_OPTS[@]}" "$passfile" | $BASE64)" || exit $?
   368                          echo "$pass" | $BASE64 -d
   369                  else

I think that this can be avoided in two possible ways:

 1. On NetBSD, if /usr/bin/base64 is available initialize BASE64 to
    `base64 -i' (but not very nice IMHO)
 2. Review all usage of `| $BASE64 -d' and always use `echo -n'
    instead of just `echo' to avoid possible whitespace characters

Probably investigating and doing `2' and push patches upstream is
the way to go, but given that the freeze for 2018Q3 is near and
converters/base64 is a pretty tiny dependency (and we do not have
any base64 as part of tool!) I have preferred to just force
password-store to always use converters/base64 instead (at least in the
short term it's probably the safest choice).

But, if anyone is interested in using NetBSD base64(1) and/or if
you are aware that there are other base64 tool that can be affected
by similar problems please let me know!