[Top][All Lists]

[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 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]