Bug#839278: oathtool: has no secure way to provide a key

Ilkka Virta writes: > On Fri, Nov 13, 2020 at 2:06 AM Simon Josefsson via OATH Toolkit general > discussions wrote: > >> 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 >>

Re: verification error

Alina Anonymous writes: > MAC OS 10.14.2,  > the results of make check install: ... > test-unsetenv../../build-aux/test-driver: line 107:  5261 Abort trap: > 6           "$@" > $log_file 2>&1FAIL: test-vasnprintfPASS: > test-verifyPASS: test-verify.shPASS: Hi. Please test newly released 2.6.3,

Bug#971440: Fixes for upstream build problems

Ian Jackson writes: > Source: oath-toolkit > Version: 2.6.1-1.4 > Severity: minor > Tags: patch, upstream > > I found two small bugs in oathtool. Hi Ian. Thanks for the report. > - $(AM_V_GEN)gengetopt --unamed-opts="KEY [OTP]" \ > + set -e; $(AM_V_GEN)gengetopt --unamed-opts="KEY

OATH Toolkit 2.6.3

Hi everyone! It has been four long years without a release. This release contains no real changes but update the build system and will serve as a declaration that we are now open for business again. I plan to review merge requests and bug reports now, and encourage you to remind me what I have

Re: Annoyance with examples in online manual

Tim Smith writes: > Hello! > > On the page at http://www.nongnu.org/oath-toolkit/oathtool.1.html > there are several > examples. Copying/pasting these, at least from Firefox on a Mac, into > a terminal fails for many of them, giving errors

Re: wrong package description

kuba writes: > Hi. > > Description at https://packages.debian.org/wheezy/oathtool says that > this package contain PAM module but it's actually not true. Hi. An updated URL is https://packages.debian.org/buster/oathtool -- and it doesn't actually say the package contains a PAM module, but that

OATH Toolkit 2.6.4

Hi! This release contains a bunch of smaller fixes. ** libpskc: New --with-xmlsec-crypto-engine to hard-code crypto engine. Fixes . Use it like --with-xmlsec-crypto-engine=gnutls or --with-xmlsec-crypto-engine=openssl if the default

Re: [sr #108736] memory corruption after pskc_build_xml()

David Woodhouse writes: > On Wed, 2020-11-11 at 18:14 +0100, Simon Josefsson wrote: >> Jaroslav Škarvada writes: >> >> > Original bug report including patch by the reporter (David >> Woodhouse): >> > https://bugzilla.redhat.com/show_bug.cgi?id=1129491 >> >> David, would you be willing to

Bug#971441: Package not built from source: gengetopt

Hi Ian and thanks for the report. I rewrote the packaging using dh instead of cdbs, and rebuilding gengetopt generated files is fixed here: https://salsa.debian.org/debian/oath-toolkit/-/commit/ba62deb912e78febc772138c771ab12ebe4d08e1 /Simon signature.asc Description: PGP signature

Bug#839278: oathtool: has no secure way to provide a key

Ian Jackson 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

OATH Toolkit 2.6.5

Hi! This release fixes the long-standing issue of suppluing secrets on the command line. Thanks to everyone who worked on discussions and patches related to this. ** oathtool: Support for reading KEY and OTP from standard input or filename. KEY and OTP may now be given as '-' to mean stdin, or

OATH Toolkit 2.6.7

Hi! This is a minor release introducing the pam_oath usersfile strings, thanks to Jason for contributing this. Please test that I didn't break the functionality for the release, alas the PAM module does not have a good self-test coverage. See below NEWS entries: ** pam_oath: Support variables

Re: libpskc 2.6.6 test-sute.log

Thanks -- that is not a serious problem, just a known memory leak in libxmlsec. You could try building with valgrind disabled or manually create a new suppressions rule and modify libpskc.supp. Unfortunately, the symbols are somewhat platform dependent since I think compilers sometimes optimize

Re: oathtool make target without for API manuals?

tis 2021-04-13 klockan 13:31 +1000 skrev Paul W. Rankin: > > On 13 Apr 2021, at 6:47 am, Simon Josefsson > > wrote: > > > > Hi! GTK-DOC is not required, and the CI/CD continously builds it > > on > > CentOS7 without gtk-doc installed, see latest build here: > > > >

Re: oathtool make target without for API manuals?

"Paul W. Rankin" via OATH Toolkit general discussions writes: >> On 14 Apr 2021, at 11:34 pm, Simon Josefsson wrote: >> >>> cd >>> /Users/pwr/Developer/pkgsrc/security/oath-toolkit/work/oath-toolkit-2.4.1 >>> && autoreconf -fi >> >> Why invoke autoreconf? Read INSTALL for installation

Re: oathtool make target without for API manuals?

"Paul W. Rankin" via OATH Toolkit general discussions writes: > Hello, > > Is it possible to build oathtool without also building the API > manuals? I ask because the gtk-doc dependency itself requires quite a > lot of dependencies (and so on, and so forth). Hi! GTK-DOC is not required, and

Re: oathtool make target without for API manuals?

"Paul W. Rankin" via OATH Toolkit general discussions writes: >> On 13 Apr 2021, at 5:13 pm, Simon Josefsson wrote: >> >> tis 2021-04-13 klockan 13:31 +1000 skrev Paul W. Rankin: >>> >>> Thanks Simon! No build failure here, I just wanted to avoid the gtk- >>> doc dependencies. I'm on macOS

Re: SHA384

Sergey Yudin writes: > We faced new login case which requires SHA384 algo. Temporary workaround is > to use RedHat's FreeOTP which supports it. Is it possible to add SHA384 ? Can you point to a specification or product specification? Do you mean HOTP or TOTP? Support for it in liboath,

Re: SHA384

Indeed, --totp=SHA384 is ignored and treated as SHA1, you can confirm this with --verbose. I opened https://gitlab.com/oath-toolkit/oath-toolkit/-/issues/37 to fix that. I looked in https://datatracker.ietf.org/doc/html/rfc6238 and SHA384 is not specified for TOTP. Can you name specific

Bug#1023038: Acknowledgement (oath-toolkit: FTBFS with xmlsec1 1.2.35)

Thank you -- the CI/CD caught this on ArchLinux before reading your email, and it is fixed now. Feel free to upload a new Debian package with your fix or the official one, and also feel free to push fixes to https://salsa.debian.org/debian/oath-toolkit

Bug#1023038: Acknowledgement (oath-toolkit: FTBFS with xmlsec1 1.2.35)

Rene Engelhard writes: > Committed and uploaded. Thank you! > (Though I needed to add the diff to the source package, building > directly from the git checkout gave me: ... > /bin/bash: line 1: ./gdoc: No such file or directory I'm not sure how you built it, but from the error it looks like

OATH Toolkit 2.6.8

OATH Toolkit provide components to build one-time password authentication systems. It contains shared C libraries, command line tools and a PAM module. Supported technologies include the event-based HOTP algorithm (RFC 4226), the time-based TOTP algorithm (RFC 6238), and Portable Symmetric Key

OATH Toolkit 2.6.9

OATH Toolkit provide components to build one-time password authentication systems. It contains shared C libraries, command line tools and a PAM module. Supported technologies include the event-based HOTP algorithm (RFC 4226), the time-based TOTP algorithm (RFC 6238), and Portable Symmetric Key

Re: Build issues

Hi Can you send me the output (stdout+stderr) from running ./configure, and the files libpskc/config.log libpskc/config.status? /Simon ons 2023-08-02 klockan 14:05 + skrev Joseph Cossette: > Sorry for late reply…I’ve other assigned duties that needed tending > to. >   > Looks like

Re: Build issues

Do you have pkg-config? Your config.log says:configure:4490: checking for pkg-configconfigure:4528: result: noconfigure:4563: checking for XML2configure:4622: result: noWhich suggests something is wrong with pkg-config./Simon24 juli 2023 kl. 23:07 skrev Joseph Cossette : Correction:   I

Re: Build issues

Hi Joseph, Thanks for your interest. Can you be specific about what your build problems are? Explaining how you tried to build the package, and what error message you got will help. OATH Toolkit is built continously in GitLab CI/CD: https://gitlab.com/oath-toolkit/oath-toolkit/-/pipelines

OATH Toolkit 2.6.10

This is to announce oath-toolkit-2.6.10, a stable release. OATH Toolkit provide components to build one-time password authentication systems. It contains shared C libraries, command line tools and a PAM module. Supported technologies include the event-based HOTP algorithm (RFC 4226), the

OATH Toolkit 2.6.11

This is to announce oath-toolkit-2.6.11, a stable release. OATH Toolkit provide components to build one-time password authentication systems. It contains shared C libraries, command line tools and a PAM module. Supported technologies include the event-based HOTP algorithm (RFC 4226), the

Bug#1063220: oath-toolkit: NMU diff for 64-bit time_t transition

Benjamin Drung writes: > Source: oath-toolkit > Dear maintainer, > > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. > > Note that this adds a versioned build-dependency on dpkg-dev, to guard > against accidental

Re: pam_oath with user_unknown=ignore

Dirk van Deun writes: > Hi, > > I really like the fact that you can use user_unknown=ignore to > introduce pam_oath gradually, and it works fine if you use one users > file to store all the secrets; but when you use a file per user > (like with usersfile=/oath/${USER}), users that do not have a

Re: pam_oath with user_unknown=ignore

Dirk van Deun writes: > On Wed, Mar 06, 2024 at 09:11:54PM +0100, Simon Josefsson wrote: >> Dirk van Deun writes: >> >> > Hi, >> > >> > I really like the fact that you can use user_unknown=ignore to >> > introduce pam_oath gradually, and it works fine if you use one users >> > file to store