[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug#839278: oathtool: has no secure way to provide a key
From: |
Ian Jackson |
Subject: |
Bug#839278: oathtool: has no secure way to provide a key |
Date: |
Fri, 13 Nov 2020 11:37:14 +0000 |
Simon Josefsson writes ("Re: Bug#839278: oathtool: has no secure way to provide
a key"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > This causes KEY and OTP to be read from files. You can specify the
> > same filename twice in which case it takes a line from each. "-"
> > means stdin.
>
> Thank you for the patch -- this makes sense. I'm not fond of the name
> 'args-from-files' though. How about this behaviour: if the supplied
> strings for KEY and/or OTP contain '/' or '\' the strings are treated as
> names of files to be read, instead of data strings? And if the string
> is '-' stdin is used.
I didn't do this because I wasn't confident that the syntax for KEY
and/or OTP didn't overlap with that for filenames. Are / and -
allowed in these values ?
> The oathtool CLI was mostly intended as a debugging tool. There were
> discussions in the past about a higher-level tool that would store
> secrets, keep track of HOTP counters, generate/validate OTPs, and
> support PSKC files. I'm not sure extending oathtool a lot further is
> appropriate. We'd might just be duplicating external efforts, such as:
I agree that substantial expansion is probably not appropriate here.
In my application all I needed was my patch.
> https://github.com/tadfisher/pass-otp
> https://github.com/matalo33/py_oathtool
Are these in Debian ?
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.