profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/FiloSottile/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Filippo Valsorda FiloSottile @Google, Go team Manhattan, NYC https://filippo.io Cryptogopher. Go security lead. @recursecenter alum. RC F'13, F2'17.

FiloSottile/age 6455

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

FiloSottile/captive-browser 325

A dedicated Chrome instance to log into captive portals without messing with DNS settings.

FiloSottile/CVE-2016-2107 174

Simple test for the May 2016 OpenSSL padding oracle (CVE-2016-2107)

FiloSottile/BERserk 91

A Go implementation of the BERserk attack against Mozilla NSS ASN.1 parsing of PKCS#1 RSA signatures with e = 3. Complete of a certificate generation tool, works with CAs in the trust store.

FiloSottile/ed25519-dalek-rustgo 86

Wrapper for curve25519-dalek using rustgo, a technique to directly call Rust code from Go programs with near-zero overhead, meant to replace manually written assembly.

FiloSottile/edwards25519 62

filippo.io/edwards25519 — A safer, faster, and more powerful low-level edwards25519 Go implementation.

benjojo/gophervista 54

It's like AltaVista, but for RFC 1436 Gopher sites

FiloSottile/blockchainr 53

Exploiting ECDSA Failures in the Bitcoin Blockchain

benjojo/traceroute-haiku 31

A thing you can traceroute and it gives you a haiku inside the trace

alecmuffett/videonion 19

video onion hackery (osx scripts)

issue commentFiloSottile/yubikey-agent

yubikey-agent blocks Yubikey Manager

Interestingly, my YubiKey 5 seems to persist the PIN cache across sessions, and even yubikey-agent restarts (but not unplug-replug cycles, as expected). In this case it would be far more acceptable to just drop the session every time.

I bet using a different applet will still trash the PIN cache, but that's probably ok.

joneskoo

comment created time in 7 hours

created tagFiloSottile/yubikey-agent

tagv0.1.5

yubikey-agent is a seamless ssh-agent for YubiKeys.

created time in 7 hours

issue commentFiloSottile/yubikey-agent

Add -new-key command

Actually, I looked again at #57 and I like the approach of having a separate command better, so let's call this yubikey-agent-keygen, with the same semantics.

FiloSottile

comment created time in 8 hours

issue commentgolang/go

proposal: net/url: provide AllowQuerySemicolons functionality for net/url rather than net/http

Not saying that we necessarily shouldn’t do this, but it’s worth noting that if you have a URL, getting the original behavior back is a single call to strings.Replace(u, “;”, “&”, -1).

chrisguiney

comment created time in 9 hours

PR closed FiloSottile/yubikey-agent

Add option to set touch policy to "cache"

This adds an optional setup flag that allows the touch policy to be set. ~to "cache for 15 seconds" instead of "always".~

~I've tried to add this feature in the least obtrusive way possible, but the command line is getting a little complex for the plain old flag package. Would there be any interest in using a CLI library in yubikey-agent?~

Closes: #52

+12 -5

9 comments

2 changed files

smlx

pr closed time in 9 hours

pull request commentFiloSottile/yubikey-agent

Add option to set touch policy to "cache"

Thank you for the PR. I don't want to add options to -setup, but I came around to adding a configurable -new-key for additional keys with more flexibility. See #95.

smlx

comment created time in 9 hours

issue closedFiloSottile/yubikey-agent

pin-policy set to always?

I have reset my old YubiKey 4 that I had lying around using both yubikey-agent -setup as well as ykman piv reset, and in both cases it prompts me for the PIN every single time, instead of once per session (which is what I expected to happen, based on the README). Is there a configuration option I'm missing?

closed time in 9 hours

teancom

issue commentFiloSottile/yubikey-agent

pin-policy set to always?

It looks like this is indeed the linked upstream issue. If you could pop in there and report your firmware version and whether it supports PIN caching, that would be great.

teancom

comment created time in 9 hours

issue commentFiloSottile/yubikey-agent

Please allow specifying a touch policy

This should be resolved by #95, please check out the plan there.

foozmeat

comment created time in 9 hours

issue commentFiloSottile/yubikey-agent

Support for more than one Yubikey plugged into the system

This will be resolved by #95

MaxRink

comment created time in 9 hours

issue openedFiloSottile/yubikey-agent

Add -new-key command

The -new-key command generates a new key in one of the numbered "retired" slots with a certificate with CN="SSH key".

The -touch-policy, -pin-policy, and -key-type flags control the respective aspects of this additional key.

There is no way to delete a key with yubikey-agent, instead the README will explain how to use YubiKey Manager for that.

yubikey-agent will support all ECDSA, Ed25519, and RSA keys in the Authorization and retired slots of all connected PIV tokens, as long as they were generated on device and the Common Name of the certificate is SSH key. (This allows ignoring age keys, which otherwise would leak to remote SSH servers.)

(This will break some current keys generated by other tools, but those were never and won't be officially supported.)

created time in 9 hours

pull request commentFiloSottile/edwards25519

Update Element SetUniformBytes comment -> SetBytes

Thank you!

bytemare

comment created time in 13 hours

push eventFiloSottile/edwards25519

Daniel Bourdrez

commit sha 18ef51f6b00a7bf767955c0f2b5ef8278b094f47

field: fix typo in SetBytes docs

view details

push time in 13 hours

PR merged FiloSottile/edwards25519

Update Element SetUniformBytes comment -> SetBytes

Fix wording in function comment.

+1 -1

0 comment

1 changed file

bytemare

pr closed time in 13 hours

startedRhetTbull/osxphotos

started time in 19 hours

issue closedFiloSottile/age

Installation on macOS failed

Environment

HOMEBREW_VERSION: 3.2.2
ORIGIN: https://github.com/Homebrew/brew
HEAD: 7d37d09709b6fbd5b89b468eb0b4438ffa0fb81c
Last commit: 3 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: aa4b76139630680884c2823727d7ffa773289fb0
Core tap last commit: 5 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 12
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: dodeca-core 64-bit kabylake
Clang: 12.0.5 build 1205
Git: 2.30.1 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.4-x86_64
CLT: 12.5.1.0.1.1623191612
Xcode: 12.5.1

I was trying to install age on my macbook pro, but installation failed and got following error message:

brew install age
==> Downloading https://github.com/FiloSottile/age/archive/v1.0.0-rc.3.zip
Already downloaded: /Users/jiangs/Library/Caches/Homebrew/downloads/3da94ea27efb60f1321ee161792e28cb0f4cc8e6e2ce27fc5739b8d26e8e1029--age-1.0.0-rc.3.zip
==> go build -o /usr/local/Cellar/age/1.0.0-rc.3/bin -ldflags -X main.Version=v1.0.0-rc.3 filippo.io/age/cmd/...
Last 15 lines from /Users/jiangs/Library/Logs/Homebrew/age/01.go:
/usr/local/Cellar/age/1.0.0-rc.3/bin
-ldflags
-X main.Version=v1.0.0-rc.3
filippo.io/age/cmd/...
runtime/cgo
In file included from gcc_libinit.c:8:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:229:66: error: unknown type name 'size_t'
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:246:43: error: unknown type name 'size_t'
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:253:66: error: unknown type name 'size_t'
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:521:1: error: unknown type name 'size_t'
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:584:23: error: unknown type name 'size_t'
gcc_libinit.c:97:18: error: variable has incomplete type 'struct timespec'
gcc_libinit.c:97:9: note: forward declaration of 'struct timespec'
gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' is invalid in C99 [-Werror,-Wimplicit-function-declaration]

Do not report this issue to Homebrew/brew or Homebrew/core!

Traceback (most recent call last):
	26: from /usr/local/Homebrew/Library/Homebrew/build.rb:229:in `<main>'
	25: from /usr/local/Homebrew/Library/Homebrew/build.rb:133:in `install'
	24: from /usr/local/Homebrew/Library/Homebrew/utils.rb:550:in `with_env'
	23: from /usr/local/Homebrew/Library/Homebrew/build.rb:138:in `block in install'
	22: from /usr/local/Homebrew/Library/Homebrew/formula.rb:1260:in `brew'
	21: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2375:in `stage'
	20: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/forwardable.rb:230:in `stage'
	19: from /usr/local/Homebrew/Library/Homebrew/resource.rb:91:in `stage'
	18: from /usr/local/Homebrew/Library/Homebrew/resource.rb:116:in `unpack'
	17: from /usr/local/Homebrew/Library/Homebrew/resource.rb:199:in `mktemp'
	16: from /usr/local/Homebrew/Library/Homebrew/mktemp.rb:63:in `run'
	15: from /usr/local/Homebrew/Library/Homebrew/mktemp.rb:63:in `chdir'
	14: from /usr/local/Homebrew/Library/Homebrew/mktemp.rb:63:in `block in run'
	13: from /usr/local/Homebrew/Library/Homebrew/resource.rb:117:in `block in unpack'
	12: from /usr/local/Homebrew/Library/Homebrew/download_strategy.rb:102:in `stage'
	11: from /usr/local/Homebrew/Library/Homebrew/download_strategy.rb:115:in `chdir'
	10: from /usr/local/Homebrew/Library/Homebrew/download_strategy.rb:115:in `chdir'
	 9: from /usr/local/Homebrew/Library/Homebrew/resource.rb:121:in `block (2 levels) in unpack'
	 8: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2395:in `block in stage'
	 7: from /usr/local/Homebrew/Library/Homebrew/utils.rb:550:in `with_env'
	 6: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2396:in `block (2 levels) in stage'
	 5: from /usr/local/Homebrew/Library/Homebrew/formula.rb:1267:in `block in brew'
	 4: from /usr/local/Homebrew/Library/Homebrew/build.rb:178:in `block (2 levels) in install'
	 3: from /usr/local/Homebrew/Library/Taps/filippo.io/homebrew-age/HomebrewFormula/age.rb:18:in `install'
	 2: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2166:in `system'
	 1: from /usr/local/Homebrew/Library/Homebrew/formula.rb:2166:in `open'
/usr/local/Homebrew/Library/Homebrew/formula.rb:2230:in `block in system': Failed executing: go build -trimpath -o /usr/local/Cellar/age/1.0.0-rc.3/bin -ldflags -X\ main.Version=v1.0.0-rc.3 filippo.io/age/cmd/... (BuildError)
	5: from /usr/local/Homebrew/Library/Homebrew/brew.rb:155:in `<main>'
	4: from /usr/local/Homebrew/Library/Homebrew/brew.rb:167:in `rescue in <main>'
	3: from /usr/local/Homebrew/Library/Homebrew/exceptions.rb:509:in `dump'
	2: from /usr/local/Homebrew/Library/Homebrew/exceptions.rb:455:in `issues'
	1: from /usr/local/Homebrew/Library/Homebrew/exceptions.rb:459:in `fetch_issues'
/usr/local/Homebrew/Library/Homebrew/utils/github.rb:60:in `issues_for_formula': undefined method `full_name' for nil:NilClass (NoMethodError)

closed time in 20 hours

roastduckkiller

issue commentFiloSottile/age

Installation on macOS failed

It looks like your Command Line Tools installation is broken, it doesn't look like it's an age-specific issue.

roastduckkiller

comment created time in 20 hours

issue closedFiloSottile/yubikey-agent

Use sockets passed in from systemd

This would allow yubikey-agent to be started socket-activated by systemd. Background: https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activation

closed time in 4 days

flokli

issue commentFiloSottile/yubikey-agent

Use sockets passed in from systemd

I would take a PR for this, but can't implement it myself as I don't regularly use Linux desktop environments.

flokli

comment created time in 4 days

issue closedFiloSottile/yubikey-agent

use notification library instead of shelling out to notify-send

main.go currently shells out to osascript or notify-send when sending a notification:

https://github.com/FiloSottile/yubikey-agent/blob/master/main.go#L337-L339

It doesn't implement any notification logic for other platforms.

"https://github.com/gen2brain/beeep provides a cross-platform library for sending desktop notifications, alerts and beeps".

It doesn't rely on notify-send being in $PATH (only as a fallback, tries via dbus first), and in addition to Darwin, it also supports sending notifications on Windows.

closed time in 4 days

flokli

issue commentFiloSottile/yubikey-agent

use notification library instead of shelling out to notify-send

github.com/gen2brain/beeep is a very large dependency tree for a tangential feature such as the notifications. I think we'll take the tradeoff here.

flokli

comment created time in 4 days

push eventFiloSottile/yubikey-agent

Filippo Valsorda

commit sha e5990fa24c111d381516b89124b79d16dcd61916

yubikey-agent: unescape pinentry output Fixes #61

view details

push time in 4 days

issue closedFiloSottile/yubikey-agent

PINs that contain '%' will not work / setup.go and main.go use different methods to get the PIN

thanks a lot for this great project. I just got new yubikeys and moved my new SSH keys to them using Yubikey-agent! While doing this I stumbled across a subtle issue though:

Right now setup.go uses terminal.ReadPassword while main.go uses github.com/gopasspw/gopass/pkg/pinentry.

The gopass pinentry communication code unfortunately has a subtle bug that replaces all % signs with %25 (see https://github.com/gopasspw/gopass/issues/1621).

Due to this bug and the different implementations it's possible to create a PIN with a % sign during setup which will then be incorrectly read as %25 from pinentry when the agent is running in the background. This will then result in strange "agent refused operation" errors when using ssh.

The unescaping should probably be fixed in gopass/pkg/pinentry but I believe both setup.go and main.go should use the same method to request the PIN for consistency. If they had used the same method the failure would've already occurred during setup (because my PIN would've been > 8 chars) and it would've been a little bit easier to track this down.

If you agree I can create a PR to unify the get pin logic in main.go and setup.go on the weekend.

closed time in 4 days

svenpeter42

startedseaofmars/vanity-age

started time in 4 days

issue commentFiloSottile/yubikey-agent

Add decryption agent functionality

A (r)age plugin that uses yubikey-agent is on the roadmap :)

fmeum

comment created time in 4 days

issue closedFiloSottile/yubikey-agent

UX/Roadmap question: importing existing keys

Hey, thanks a lot for creating this project!

One question comes to my mind: is it possible to import existing SSH keys to a Yubikey (using any mechanism, not necessarily yubikey-agent itself) so that yubikey-agent can use them just like the keys it created on the device? Assuming it's not possible right now and it's just something that's not implemented in yubikey-agent – is it likely to exist in the future? Are pull requests implementing it welcome?

My use case is to generate a key on a trusted secure machine (temporary, disposable and clean system, no network etc.), upload it to a Yubikey and also store an encrypted copy on a usb-stick for extra safety in case my Yubikey stops working at some point. (Having multiple Yubikeys with different SSH keys on each of them is not suitable for me.)

closed time in 4 days

jstasiak

issue commentFiloSottile/yubikey-agent

UX/Roadmap question: importing existing keys

I understand the use case, but it's an advanced scenario that we will not support in -setup. We might allow using such a key once it's been generated with some other tool. See #91 for that.

jstasiak

comment created time in 4 days

pull request commentFiloSottile/yubikey-agent

Allow generating the private key on the computer

Thank you for the PR, but I don't want to support importing keys in -setup. yubikey-agent is a simple opinionated tool that makes these choices for the user.

I might consider fixes that make it possible to import keys with other tools and then use them with yubikey-agent, if they are small enough, but see #91.

jstasiak

comment created time in 4 days

PR closed FiloSottile/yubikey-agent

Allow generating the private key on the computer

This is to allow creating backups of the private key in case the YubiKey gets lost or damaged. The word "insecurely" is appended to the name of the switch and a long warning produced in order to make people who don't know what they're doing turn away and stop what they're doing.

This is possible since piv-go 1.7.0[1] so I allowed myself to bump the version of this requirement.

While I do have several doubts about approaching this (see below) I believe this is a useful thing to have. What I'm unsure about is:

  • The code quality (I'm not writing Go day to day)
  • I may have done something stupid cryptography-wise here, I'm not a cryptographer or a security specialist
  • How to warn properly so that people not knowing what they're doing don't use the new switch – I think I've done a decent job here
  • Should this be mentioned in the readme? I mentioned it for documentation purposes
  • Should this be mentioned in the --help output? The existing --really-delete-all-piv-keys flag is not there so I skipped it
  • Should there be advice that when this option is used it's better to do it on a clean system, on a trusted machine, offline and airgapped ideally, and any potential backups should be encrypted and stored securely?
  • Should the main agent daemon always handle keys that fail attestation (caused by generating on the computer instead of on the device) like I added here or maybe make this configurable with a switch?

Closes GH-65.

[1] https://github.com/go-piv/piv-go/pull/83#issuecomment-740707527

+64 -10

3 comments

5 changed files

jstasiak

pr closed time in 4 days

issue closedFiloSottile/yubikey-agent

Feature request: User configurable delay before "Waiting for YubiKey touch..." notification

I don't have my yubikey in direct eye view, would be convenient if the desktop notification showed immediately or on a configurable delay

closed time in 4 days

theblazehen