howeyc / gopass Goto Github PK

As per the spec, println() is not guaranteed to be available. You should use os.Stdout.Write([]byte{'\n'}) instead.

Please see mislav/hub#1262 for the description of the issue, and mislav/hub@70d7bb6#commitcomment-18977708 for the possible root cause, which is in howeyc/gopass/pass.go.

A summary:

• applications that use howeyc/gopass to ask for passwords end up displaying the prompts with a stair-case effect, i.e.
  
• this is likely caused by pass.go emitting a \n before it restores the terminal state, which keeps the stty onlcr flag unset

so im trying to use a tool that imports gopass to enter a password, but it isnt working. does this have support for termux on android?

Any interest in exporting the getch function? Or perhaps creating a getch package?

The readme makes it pretty clear that people should just use the stdlib terminal repo now. Id suggest:

• explicitly archiving the repo
• closing all the issues and pull requests referencing the closture
• updating the readme to mention that it has been archived and just there as read-only

Hey there

I'm building this library as part of shazow/ssh-chat. Compiling fails on OpenIndiana with GCC-7 & GCC-9 with the following error:

../go/pkg/mod/github.com/howeyc/[email protected]/terminal_solaris.go:32:6: terminalState redeclared in this block
        previous declaration at ../go/pkg/mod/github.com/howeyc/[email protected]/terminal.go:23:6
../go/pkg/mod/github.com/howeyc/[email protected]/terminal_solaris.go:39:6: isTerminal redeclared in this block
        previous declaration at ../go/pkg/mod/github.com/howeyc/[email protected]/terminal.go:27:29
../go/pkg/mod/github.com/howeyc/[email protected]/terminal_solaris.go:49:6: makeRaw redeclared in this block
        previous declaration at ../go/pkg/mod/github.com/howeyc/[email protected]/terminal.go:31:43
../go/pkg/mod/github.com/howeyc/[email protected]/terminal_solaris.go:67:6: restore redeclared in this block
        previous declaration at ../go/pkg/mod/github.com/howeyc/[email protected]/terminal.go:39:51

when using running getPassMasked on windows terminal emulators like git bash and Cmder, the password it not masked and is printed after it is submitted.

I am running on golang version 1.9

Hi,

Unfortunately this is one of those situations where package and version management is lacking in the Go ecosystem badly.

Your recent change to GetPasswd's return signature, which now returns ([]byte, error) (6da5953 in pass.go) breaks a downstream dependent library, gopkg.in/godo.v2, which expected only a single return value (see here).

I'd suggest you consider also using gopkg.in and version new changes, and I'll notify the repo/owner of godo.v2 about the breaking change and cross-reference this issue. They will have to update their code as well, but if you version your changes and pin them with gopkg in the future, downstream packages won't break like they did here.

Thanks,
Mike

The change yesterday for moving to using go.crypto creates a Go 1.1 dependency.

$ go version
go version go1.0.3
$ go get code.google.com/p/go.crypto/ssh/terminal
# code.google.com/p/go.crypto/ssh/terminal
../../../../code.google.com/p/go.crypto/ssh/terminal/util.go:27: undefined: syscall.Termios

Although Go 1.1 is looking pretty nice and is close to release, Go 1.0.3 is still the current stable release. To mitigate this, we've simply forked and reverted internally, but wanted to let you know as it breaks compatibility for anyone else who is using the library and not on Go 1.1 or tip.

There should be some way to unblock a blocked GetPasswd call if you'd like to stop waiting for user input after a certain timeout for example.

Common ways might be to allow passing in a context or to offer a Cancel() method somehow.

It might be best to add a GetPasswdWithContext function which adds the context param as input.

The only thing I'm unsure about is how the interruptability of waiting on stdin might work.

Thanks!

The internal getch function has completely different error-handling behavior depending on platform:

• The BSD code ignores the potential error (a -1 return) from the read() call, so if it fails, it returns an undefined value, since it reads stack memory.
• The *nix code panics (not ideal)
• I'm not a Windows expert, but it looks like it ignores the errors completely. I'm imagining the return value is zero since Go zeroes the value?

My proposed fix is to make the functions in this package return an error. I know this is a breaking API change. To maintain compatibility, you could phase this in by adding new functions with the proper behavior and adding a deprecation notice to the docs of the existing functions. Might I recommend Read for the function name, since then callers will use gopass.Read instead of gopass.GetPasswd (as per Effective Go)?

After getPassword has been called, any subsequent calls to bufio.ReadString fail to read any data and stop the program from continuing on once called. It even prevents Ctrl+C from terminating the program.

I think we need rewrite getChar() in cygwin terminal.

The OPENSOLARIS.LICENSE file states:

Unless otherwise noted, all files in this distribution are released
under the Common Development and Distribution License (CDDL).
Exceptions are noted within the associated source files.

Unfortunately, none of the non-solaris source files include any license statements, which makes them covered by the more restrictive OPENSOLARIS.LICENSE terms and not LICENSE.txt terms.

haha

Making a release is easy on github and it would help 3rd-party vendors (linux distros, BSDs, etc) to package your software.

See https://code.google.com/p/gopass/source/browse/gopass.go for a way of handling this.

The code:

// For some reason n returned seems to big by 2 (Null terminated maybe?)
if n > 2 {
    n -= 2
}

b := []byte(string(utf16.Decode(line[:n])))

I think can result in trying to get line[-2] and it causes a panic, likely it needs to validate n>0

runtime error: slice bounds out of range

goroutine 16 [running]:
runtime.panic(0x7f5b80, 0xa92f4f)
c:/go/src/pkg/runtime/panic.c:248 +0x1d3
github.com/howeyc/gopass.getch(0x71a400)
D:/dev/cygwin/home/FCASSI1/go/src/github.com/howeyc/gopass/win.go:37 +0x5ff
github.com/howeyc/gopass.GetPasswd(0x0, 0x0, 0x0)
D:/dev/cygwin/home/FCASSI1/go/src/github.com/howeyc/gopass/pass.go:13 +0x151
github.com/github/hub/github.(*Config).PromptForPassword(0xc08207aea0, 0xc082026f5c, 0x1a, 0xc082000d58, 0x5, 0x848110, 0x0)

The password is still echoed when running the binary in cygwin/mintty

I am getting the following panic on OS X:

panic: operation not supported by device [recovered]
    panic: operation not supported by device
...
github.com/howeyc/gopass.getch(0xc20801e300)
    ...src/github.com/howeyc/gopass/nix.go:13 +0x74
github.com/howeyc/gopass.getPasswd(0x0, 0x0, 0x0, 0x0)
    ...src/github.com/howeyc/gopass/pass.go:18 +0x11f
github.com/howeyc/gopass.GetPasswd(0x0, 0x0, 0x0)
    ...src/github.com/howeyc/gopass/pass.go:37 +0x3e

The bitmasking in the Windows implementation of getch is wrong: it uses XOR instead of AND NOT. The proper operation is:

newMode = mode &^ (echoMode | lineMode)

Impact: If the console is already in a non-echoing mode when getch is called, it puts it into echoing mode.

I can imagine that some users would like to have a visual feedback in form of "*" characters for each password character inserted.

I was expecting Ctrl+C to cancel password entry, instead it does nothing at all.