from:"Simon Josefsson via OATH Toolkit general discussions"

OATH Toolkit 2.6.12

2024-10-04 Thread Simon Josefsson via OATH Toolkit general discussions

This is to announce oath-toolkit-2.6.12, 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 time-based TOTP algorithm (RFC 6238), and
Portable Symmetric Key Container (PSKC, RFC 6030) to manage secret key
data.  OATH stands for Open AuTHentication, which is the organization
that specify the algorithms.

The following components are included:

 * liboath: A shared and static C library for OATH handling.
 * oathtool: A command line tool for generating and validating OTPs.
 * pam_oath: A PAM module for pluggable login authentication for OATH.
 * libpskc: A shared and static C library for PSKC handling.
 * pskctool: A command line tool for manipulating PSKC data.

The project's web page is available at:
  https://www.nongnu.org/oath-toolkit/

Documentation for the command line tools oathtool and pskctool:
  https://www.nongnu.org/oath-toolkit/oathtool.1.html
  https://www.nongnu.org/oath-toolkit/pskctool.1.html

Tutorial on PSKC:
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial.html

Manual for PAM module:
  https://www.nongnu.org/oath-toolkit/pam_oath.html

Liboath Manual:
  https://www.nongnu.org/oath-toolkit/liboath-api/liboath-oath.h.html

Libpskc Manual
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-reference.html

General information on contributing:
  https://www.nongnu.org/oath-toolkit/contrib.html

OATH Toolkit GitLab project page:
  https://gitlab.com/oath-toolkit/oath-toolkit

OATH Toolkit Savannah project page:
  https://savannah.nongnu.org/projects/oath-toolkit/

Code coverage charts:
  https://oath-toolkit.gitlab.io/oath-toolkit/coverage/

Clang code analysis:
  https://oath-toolkit.gitlab.io/oath-toolkit/clang-analyzer/

Coverity report:
  https://scan.coverity.com/projects/oath-toolkit

If you need help to use the OATH Toolkit, or want to help others, you
are invited to join our oath-toolkit-help mailing list, see:
  https://lists.nongnu.org/mailman/listinfo/oath-toolkit-help

Here are the compressed sources and a GPG detached signature:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.12.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.12.tar.gz.sig

Here is a signed git-archive style minimal source code archive:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.12-src.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.12-src.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

0bfb6ad29d59628487c9e180c7a43f4ca301e4d1  oath-toolkit-2.6.12.tar.gz
cafdf739b1ec4b276441c6aedae6411434bbd870071f66154b909cc6e2d9e8ba  
oath-toolkit-2.6.12.tar.gz

0a652af2c638789f99a030097fc718e3cb09615b  oath-toolkit-2.6.12-src.tar.gz
7c6a3c9043941bc3f1b37bd50a6cb8d508c1e42bff631292f938e08a377a36ff  
oath-toolkit-2.6.12-src.tar.gz

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify oath-toolkit-2.6.12.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key si...@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- https://josefsson.org/key-20190320.txt | gpg --import

NEWS

* Version 2.6.12 (released 2024-10-03)

** pam_oath: Drop privs when ${HOME} is used in the usersfile= setting.
Reported by Fabian Vogt (SUSE), and associated with CVE-2024-47191.
See .
Security bug triggered by new feature in pam_oath v2.6.7 released on
2021-05-01 with the USER/HOME placeholder strings, see
.

Quoting a writeup in an alternate patch by Matthias Gerstner (SUSE):
With the addition of the possibility to place a usersfile also into a
user's home directory via variable expansion of ${HOME} and ${USER} in
the `usersfile=` path specification, security issues sneaked in.  The
PAM process usually runs with root privileges.  The file operations in
an unprivileged user's home directory follow symlinks both when
reading and creating files, allowing for a potential local root
exploit, because of the `fchown()` performed on the newly created
usersfile.

We drop privileges to the user that is being logged into, assuming it
has the necessary permissions for the usersfile belonging in their
home directory.  This restricts the ability for non-ro

[SECURITY ADVISORY] oath-toolkit: pam_oath usersfile ${HOME} privilege escalation

2024-10-04 Thread Simon Josefsson via OATH Toolkit general discussions

OATH Toolkit pam_oath usersfile ${HOME} privilege escalation


Security Vulnerability
--

OATH Toolkit provides two components liboath and pam_oath.  Pam_oath
is normally run as root and assumes that the "usersfile" path setting
value points to a root-controlled and protected file containing the
OATH secrets (cryptographic HMAC keys) for users.

The documentation suggests using a root-owned /etc/users.oath and to
do "chmod go-rw /etc/users.oath" on it.  The design assumes that file
permissions are set up to prevent malicious read or writes to the
credential file by unauthorized users.  Whether file permissions are
setup correctly or not is not checked by the code.

On every successful authentication, the file is rewritten to prevent
OTP replay attacks.  The rewriting logic works by acquiring a POSIX
file lock on a newly created *.lock file (in the same directory), and
then writing file content to a newly created *.new file (also in the
same directory).  File ownership of the new file is set to the same as
the original file.  The original usersfile is replaced atomically with
the newly created file.

With the introduction of the ${HOME} indirection variable in the
usersfile parameter the design assumptions no longer holds.  The
feature was added in version 2.6.7 released on 2021-05-01.

A typical setup when ${HOME} is used in a usersfile value such as
usersfile=${HOME}/.config/oath.secrets is to allow users to manage
their own credentials.  The file is owned by the user who is
responsible for adding the secret to it, and to set read/write
permissions on the file appropriately.

The security problem is easy to exploit.  To demonstrate the
vulnerability with a vulnerable version and configuration, create a
symbolic link $HOME/.config/oath.secrets.new that points to a
privileged file such as /etc/shadow.  After successful login as the
user, pam_oath/liboath has followed the symbolic link and rewrote the
target file with new updated OATH credentials and sets ownership of
that file to the user.  The user is now able to modify /etc/shadow.

We are not aware of any active exploits in the wild of this flaw.

Affected versions and configurations


OATH Toolkit pam_oath and liboath version 2.6.7 to version 2.6.11 are
affected.  Version 2.6.12 prevents the attack.

The attack requires that the "usersfile" setting has a file or path
component that is in a vulnerable location.  The common setup with a
write/read-protected usersfile=/etc/users.oath setup is not
vulnerable.

While admin's may specify a "usersfile" in a world-writeable directory
like /tmp we regard that as a configuration error.  In most scenarios,
only "usersfile" with ${HOME} in them should be regarded as a
vulnerable configuration.

One vulnerable setting is usersfile=/home/joe/.config/system.oath
giving joe the ability to modify root-owned files, assuming a non-root
user joe with write access to anything below /home/joe.  This is
somewhat similar to having a system SSH configuration of HostKey
/home/joe/ssh_hostkey which we believe is unlikely and also consider
to be a configuration error.

Another example is via the ${USER} setting as in
usersfile=/home/${USER}/.config/oath.secrets giving any non-root user
the ability to control system files, assuming they have write access
to anything below /home/${USER}.  We have improved the documentation
regarding ${USER} to be for those settings where root-controlled
per-user files are desired.  The intended use of ${USER} strings are
for setups like usersfile=/var/oath/oath.${USER}.secrets where the
files are per-user but owned by root and have file permissions setup
to prevent read/write from the user.  The root-ownership and file
permission should prevent users from being able to reach their OATH
credentials when ${USER} is used.

The pam_oath fix only address configurations that uses ${HOME} and not
any other vulnerable configurations.  The liboath fix prevent direct
attacks via *.new and *.lock symlinks, but other scenarios are
possible and the input to oath_authenticate_usersfile() MUST be a
trusted filename -- suitable sanitization is application-dependent.

Details
---

The vulnerable code in liboath is inside
oath_authenticate_usersfile(), quoting code from version 2.6.11 which
can be reviewed here:

https://gitlab.com/oath-toolkit/oath-toolkit/-/blob/oath-toolkit-2.6.11/liboath/usersfile.c?ref_type=tags#L324

The lock file is acquired:

  /* Open lockfile. */
  {
int l;
l = asprintf (&lockfile, "%s.lock", usersfile);
if (lockfile == NULL || ((size_t) l) != strlen (usersfile) + 5)
  return OATH_PRINTF_ERROR;
lockfh = fopen (lockfile, "w");
if (!lockfh)
  {
free (lockfile);
return OATH_FILE_CREATE_ERROR;
  }
  }

Since fopen("w") is used any existing file with the predictable *.lock
filename will be opened, including if that file happens to

Re: pam_oath with user_unknown=ignore

2024-03-07 Thread Simon Josefsson via OATH Toolkit general discussions

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 all the secrets; but when you use a file per user 
>> > (like with usersfile=/oath/${USER}), users that do not have a secret
>> > yet do need an empty file for PAM_USER_UNKNOWN to be returned;
>> > without, you get a file-not-found kind of error instead.
>> >
>> > It is debatable whether this is a bug or just unexpected behaviour,
>> > but to me it would make more sense if in such a configuration, a
>> > missing file would also lead to PAM_USER_UNKNOWN.  
>> 
>> Yes this makes somewhat sense.  The patch to get your behaviour would
>> probably be something like this:
>> 
>> diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
>> index 25eb83e..f5ae490 100644
>> --- a/pam_oath/pam_oath.c
>> +++ b/pam_oath/pam_oath.c
>> @@ -303,7 +303,7 @@ pam_sm_authenticate (pam_handle_t *pamh,
>>  DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
>>oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
>>oath_strerror (rc), ctime (&last_otp)));
>> -if (rc == OATH_UNKNOWN_USER)
>> +if (rc == OATH_NO_SUCH_FILE || rc == OATH_UNKNOWN_USER)
>>{
>>  retval = PAM_USER_UNKNOWN;
>>  goto done;
>> 
>> Although since (IIRC) 'user_unknown=ignore' is handled by the PAM layer
>> and not the pam_oath module, I worry that if we start to return
>> PAM_USER_UNKNOWN on file-not-found errors, we will cause unwanted
>> behaviour in other situations.
>> 
>> One ugly way to resolve this is to introduce a new keyword that cause
>> this particular behaviour to happen, for example
>> 'missing_usersfile_leads_to_user_unknown' causes OATH_NO_SUCH_FILE
>> errors to be translated into PAM_USER_UNKNOWN.  What do you think?
>> Would you like to make an attempt to make a patch?
>> 
>> /Simon
>
> We can try to do the right thing based on the usersfile parameter:
>
> - if usersfile does not contain a variable, then OATH_NO_SUCH_FILE
> is still an error;
>
> - if usersfile starts with ${HOME}, OATH_NO_SUCH_FILE gives rise to
> PAM_USER_UNKNOWN, except if the home directory in question does
> not exist, as then it is safer to assume that something went wrong
> (like homes not being mounted) and keep calling it an error;
>
> - if usersfile starts with a literal path that ends with a slash,
> followed by a variable (presumably ${USER}), followed by whatever,
> OATH_NO_SUCH_FILE gives rise to PAM_USER_UNKNOWN, except if the
> literal path part does not exist OR is an empty directory -- the
> is-empty test can be added because we can reasonably assume that at
> least one user on the system has configured oath; 
>
> - other cases are just weird, so the error may stay an error.
>
> Agree ?

This sounds complicated to me since it assumes even further semantic
understanding of the usersfile path value.  Understanding the difference
between a missing and unreadable home directory can be difficult for
network file systems.  Right now the error is returned on all fopen()
failures, which includes a number of different error conditions.  It
isn't clear to me that there aren't reasonable scenarios where a missing
usersfile should NOT lead PAM_USER_UNKNOWN errors, but a hard error:
maybe someone is using the current semantics and has a hierarchy of
usersfile for users, and expect the current behaviour.

It still seems simpler to introduce a new keyword that triggers
PAM_USER_UNKNOWN for OATH_NO_SUCH_FILE usersfile error.  Then this can
be documented as a new supported feature.

/Simon


signature.asc
Description: PGP signature

Re: pam_oath with user_unknown=ignore

2024-03-06 Thread Simon Josefsson via OATH Toolkit general discussions

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 secret
> yet do need an empty file for PAM_USER_UNKNOWN to be returned;
> without, you get a file-not-found kind of error instead.
>
> It is debatable whether this is a bug or just unexpected behaviour,
> but to me it would make more sense if in such a configuration, a
> missing file would also lead to PAM_USER_UNKNOWN.  

Yes this makes somewhat sense.  The patch to get your behaviour would
probably be something like this:

diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
index 25eb83e..f5ae490 100644
--- a/pam_oath/pam_oath.c
+++ b/pam_oath/pam_oath.c
@@ -303,7 +303,7 @@ pam_sm_authenticate (pam_handle_t *pamh,
 DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
  oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
  oath_strerror (rc), ctime (&last_otp)));
-if (rc == OATH_UNKNOWN_USER)
+if (rc == OATH_NO_SUCH_FILE || rc == OATH_UNKNOWN_USER)
   {
retval = PAM_USER_UNKNOWN;
goto done;

Although since (IIRC) 'user_unknown=ignore' is handled by the PAM layer
and not the pam_oath module, I worry that if we start to return
PAM_USER_UNKNOWN on file-not-found errors, we will cause unwanted
behaviour in other situations.

One ugly way to resolve this is to introduce a new keyword that cause
this particular behaviour to happen, for example
'missing_usersfile_leads_to_user_unknown' causes OATH_NO_SUCH_FILE
errors to be translated into PAM_USER_UNKNOWN.  What do you think?
Would you like to make an attempt to make a patch?

/Simon

signature.asc
Description: PGP signature

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

2024-02-29 Thread Simon Josefsson via OATH Toolkit general discussions

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 backports with a wrong ABI.

Thanks - for how long will the dpkg-dev build-depends be necessary?

/Simon


signature.asc
Description: PGP signature

OATH Toolkit 2.6.11

2024-01-11 Thread Simon Josefsson via OATH Toolkit general discussions

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 time-based TOTP algorithm (RFC 6238), and
Portable Symmetric Key Container (PSKC, RFC 6030) to manage secret key
data.  OATH stands for Open AuTHentication, which is the organization
that specify the algorithms.

The following components are included:

 * liboath: A shared and static C library for OATH handling.
 * oathtool: A command line tool for generating and validating OTPs.
 * pam_oath: A PAM module for pluggable login authentication for OATH.
 * libpskc: A shared and static C library for PSKC handling.
 * pskctool: A command line tool for manipulating PSKC data.

The project's web page is available at:
  https://www.nongnu.org/oath-toolkit/

Documentation for the command line tools oathtool and pskctool:
  https://www.nongnu.org/oath-toolkit/oathtool.1.html
  https://www.nongnu.org/oath-toolkit/pskctool.1.html

Tutorial on PSKC:
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial.html

Manual for PAM module:
  https://www.nongnu.org/oath-toolkit/pam_oath.html

Liboath Manual:
  https://www.nongnu.org/oath-toolkit/liboath-api/liboath-oath.h.html

Libpskc Manual
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-reference.html

General information on contributing:
  https://www.nongnu.org/oath-toolkit/contrib.html

OATH Toolkit GitLab project page:
  https://gitlab.com/oath-toolkit/oath-toolkit

OATH Toolkit Savannah project page:
  https://savannah.nongnu.org/projects/oath-toolkit/

Code coverage charts:
  https://oath-toolkit.gitlab.io/oath-toolkit/coverage/

Clang code analysis:
  https://oath-toolkit.gitlab.io/oath-toolkit/clang-analyzer/

If you need help to use the OATH Toolkit, or want to help others, you
are invited to join our oath-toolkit-help mailing list, see:
  https://lists.nongnu.org/mailman/listinfo/oath-toolkit-help

Here are the compressed sources and a GPG detached signature:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.11.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.11.tar.gz.sig

Here are the SHA1 and SHA224 checksums:

7e365d0fa892c4d1493585751adaec0ebd07d66e  oath-toolkit-2.6.11.tar.gz
a6a91cfe8aa5498d032278aa4e759e39c9b87e04f68aed55a68c9efa  
oath-toolkit-2.6.11.tar.gz

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify oath-toolkit-2.6.11.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key si...@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- https://josefsson.org/key-20190320.txt | gpg --import

NEWS

* Version 2.6.11 (released 2024-01-03)

** liboath: Handle invalid base32 encoded secrets.  Fixes: #41.
The gnulib update in version 2.6.10 made the base32 encoding functions
reject invalid encodings, but it appears as if these are wildly used.
We now accept invalid encodings again.  Thanks to Dorancé Martínez and
Seres Bendegúz for reports.

Happy hacking,
Simon


signature.asc
Description: PGP signature

OATH Toolkit 2.6.10

2024-01-02 Thread Simon Josefsson via OATH Toolkit general discussions

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 time-based TOTP algorithm (RFC 6238), and
Portable Symmetric Key Container (PSKC, RFC 6030) to manage secret key
data.  OATH stands for Open AuTHentication, which is the organization
that specify the algorithms.

The following components are included:

 * liboath: A shared and static C library for OATH handling.
 * oathtool: A command line tool for generating and validating OTPs.
 * pam_oath: A PAM module for pluggable login authentication for OATH.
 * libpskc: A shared and static C library for PSKC handling.
 * pskctool: A command line tool for manipulating PSKC data.

The project's web page is available at:
  https://www.nongnu.org/oath-toolkit/

Documentation for the command line tools oathtool and pskctool:
  https://www.nongnu.org/oath-toolkit/oathtool.1.html
  https://www.nongnu.org/oath-toolkit/pskctool.1.html

Tutorial on PSKC:
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial.html

Manual for PAM module:
  https://www.nongnu.org/oath-toolkit/pam_oath.html

Liboath Manual:
  https://www.nongnu.org/oath-toolkit/liboath-api/liboath-oath.h.html

Libpskc Manual
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-reference.html

General information on contributing:
  https://www.nongnu.org/oath-toolkit/contrib.html

OATH Toolkit GitLab project page:
  https://gitlab.com/oath-toolkit/oath-toolkit

OATH Toolkit Savannah project page:
  https://savannah.nongnu.org/projects/oath-toolkit/

Code coverage charts:
  https://oath-toolkit.gitlab.io/oath-toolkit/coverage/

Clang code analysis:
  https://oath-toolkit.gitlab.io/oath-toolkit/clang-analyzer/

If you need help to use the OATH Toolkit, or want to help others, you
are invited to join our oath-toolkit-help mailing list, see:
  https://lists.nongnu.org/mailman/listinfo/oath-toolkit-help

Here are the compressed sources and a GPG detached signature:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.10.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.10.tar.gz.sig

Here are the SHA1 and SHA224 checksums:

3e346ef1218e0f2894e6b2ba643c43b7afae175c  oath-toolkit-2.6.10.tar.gz
7c90d32c50102864f4cd5a08eac7f4323b8f67a18df2c84ba867c886  
oath-toolkit-2.6.10.tar.gz

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify oath-toolkit-2.6.10.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key si...@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- https://josefsson.org/key-20190320.txt | gpg --import

NEWS

* Version 2.6.10 (released 2024-01-03)

** Building from git uses a ./bootstrap script instead of 'make bootstrap'.

** Build fixes for Windows.
In particular, don't use filenames "aux.h" and "aux.c" which interact
badly with the AUX special filename.

** Build fixes for Arch Linux.

** Various build fixes including updated gnulib files.
One remaining gnulib self-test disabled.

Happy hacking,
Simon


signature.asc
Description: PGP signature

Re: SHA384

2023-09-08 Thread Simon Josefsson via OATH Toolkit general discussions

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 products that generate
these kind of QR-codes or TOTP secrets?  Supporting TOTP-SHA384 is
quite weird to me: there is no real practical speed or security
difference compared to SHA512 for the small output space that TOTP
uses.  I'm not saying NO to support it, but we need more details.

/Simon

fre 2023-09-08 klockan 16:43 +0300 skrev Sergey Yudin:
> Simon, thank you very much for your answer! I mean TOTP and oathtool.
> We've got QR-code for our new logins which looks like this:
> QR-
> Code:otpauth://totp/username:someuuid?issuer=username&secret=LONGBASE
> 32KEY&digits=6&algorithm=SHA384&period=30
> 
> oathtool --totp=SHA384 -d 6 -s 30 -b "BASE32KEY..." gives wrong code.
> I thought SHA384 just ignored
> 
> Regards...
> 
> On Tue, Sep 5, 2023 at 11:21 AM Simon Josefsson 
> wrote:
> > 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, oathtool, pam_oath,
> > libpskc,
> > and/or pskctool?  What kind of support?
> > 
> > /Simon
> 
> 
> -- 
> Regards..

signature.asc
Description: This is a digitally signed message part

Re: SHA384

2023-09-05 Thread Simon Josefsson via OATH Toolkit general discussions

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, oathtool, pam_oath, libpskc,
and/or pskctool?  What kind of support?

/Simon

signature.asc
Description: PGP signature

Re: Build issues

2023-08-02 Thread Simon Josefsson via OATH Toolkit general discussions

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 pkg-config is already installed.  When I did this, it
> produced the following output:
>  
> # sudo apt install pkg-config
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> pkg-config is already the newest version (0.29.2-1ubuntu3).
> pkg-config set to manually installed.
> 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
>  
>  
> Hope this helps.
>  
> Thanks in advance.
>  
>  
> From:Simon Josefsson 
> Date: Wednesday, July 26, 2023 at 5:40 AM
> To: Joseph Cossette 
> Cc: oath-toolkit-help@nongnu.org 
> Subject: Re: Build issues
> Do you have pkg-config? Your config.log says:
>  
> configure:4490: checking for pkg-config
> configure:4528: result: no
> configure:4563: checking for XML2
> configure:4622: result: no
>  
> Which suggests something is wrong with pkg-config.
>  
> /Simon
> 
> 
> > 24 juli 2023 kl. 23:07 skrev Joseph Cossette
> > :
> >  
> > Correction:
> >  
> >    1. I get oathtool and libpath (and ubuntu builds pam) just fine.
> >  
> > I get oathtool and liboath (and ubuntu builds pam) just fine.
> >  
> > From:oath-toolkit-help-bounces+jcossej=jci@nongnu.org
> >  on behalf of
> > Joseph Cossette 
> > Date: Monday, July 24, 2023 at 4:52 PM
> > To: Simon Josefsson 
> > Cc: oath-toolkit-help@nongnu.org 
> > Subject: Re: Build issues
> >  
> > Other than the latex/doc tools, I already had everything installed
> > mentioned in your link below, including libxmlsec.
> >  
> > Again, there is no “build error”.  It builds oathtool and liboath
> > in Yocto ARM and Ubuntu 22.04 (Ubuntu also build the pam too) just
> > fine.
> >  
> > What I don’t get is the pskc artifacts.  If I do a build from using
> > the configure command line:
> >  
> > ./configure --prefix=$PWD/../built --enable-pskc
> >  
> > I get oathtool and libpath (and ubuntu builds pam) just fine.  But
> > it doesn’t build any pskc artifacts…I believe it’s because the
> > configure script doesn’t find libxml2…so it never attempts to run
> > configure in libpskc and pskctool.
> >  
> > So there is no “build error” to see…the error is that it’s not
> > building the requested pskc artifacts…how to build these when it
> > can’t locate libxml2 ?
> >  
> > I believe our Yocto ARM build was taken directly from the
> > OpenEmbedded repository, and is an older version (oath 2.6.2), but
> > it is broken in regards to pskc artifacts also. We tried replacing
> > it with the newsest version, but it too has the same problem.
> >  
> > Hope this helps.
> >  
> >  
> > From:Simon Josefsson 
> > Date: Monday, July 24, 2023 at 11:54 AM
> > To: Joseph Cossette 
> > Cc: oath-toolkit-help@nongnu.org 
> > Subject: Re: Build issues
> > Hi
> >  
> > Can you qoute the build error you get from “make”? You need
> > libxmlsec, did you use the commands suggested here:
> >  
> >  > 570ddb06edf56a2312253c5872489847a0f385112ddbcd71ccfa1570febab5d2.jp
> > g> CONTRIBUTING.md · master · oath-toolkit / oath-toolkit · GitLab
> > gitlab.com
> >  
> > In particular: 
> > apt-get install make git autoconf automake libtool bison gengetopt
> > valgrind apt-get install libpam0g-dev libxmlsec1-dev libxml2-utils
> > apt-get install help2man gtk-doc-tools libglib2.0-dev dblatex
> >  
> > /Simon
> > 
> > 
> > 
> > 
> > > 24 juli 2023 kl. 17:46 skrev Joseph Cossette
> > > :
> > >  
> > > Sure.
> > >  
> > > I created a VM from standard desktop Ubuntu 22.04.2 LTS .iso
> > > file.  Added build essentials and some other tools for
> > > development, as well as any other noted dependencies for oath
> > > toolkit (Linux pam headers, libxml2, etc.,…).
> > >  
> > > Used the following command line to configure:
> > >  
> > > /configure --prefix=$PWD/../built --enable-pskc
> > >  
> > > Configure ends with the following lines, which show that pskc
> > > would not be built:
> > >  
> > >   version:  2.6.9
> > >   Install prefix:   /mnt/hgfs/snc2/third_party/oath/oath-toolkit-
> > > 2.6.9/../built
> > >   Compiler: gcc
> > >   Build PAM module: yes
> > >   PSKC: no
> > >  
> > > I’ve attached the config.log & config.status file for your
> > > perusal.  In searching for XML2 in the config log file it appears
> > > to indicate that it didn’t find it, even though it is installed
> > > on the system.  It then of course doesn’t even attempt to build
> > > any pskc artifacts, as where if it at least configured for pskc
> > > artifacts the resolution could then be deferred to
> > > compilation/linking steps, which is typically easier to handle
> > > for embedded systems.
> > >  
> > > As I previously mentioned, oathtool and it’s dependent library
> > > liboath appear to be building correctly for both Ubuntu and Yo

Re: Build issues

2023-07-26 Thread Simon Josefsson via OATH Toolkit general discussions

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 get oathtool and libpath (and ubuntu builds pam) just fine.
 
I get oathtool and liboath (and ubuntu builds pam) just fine.
 

From:
oath-toolkit-help-bounces+jcossej=jci@nongnu.org  on behalf of Joseph Cossette 
Date: Monday, July 24, 2023 at 4:52 PM
To: Simon Josefsson 
Cc: oath-toolkit-help@nongnu.org 
Subject: Re: Build issues

 
Other than the latex/doc tools, I already had everything installed mentioned in your link below, including libxmlsec.
 
Again, there is no “build error”.  It builds oathtool and liboath in Yocto ARM and Ubuntu 22.04 (Ubuntu also build the pam too) just fine.
 
What I don’t get is the pskc artifacts.  If I do a build from using the configure command line:
 
./configure --prefix=$PWD/../built --enable-pskc

 
I get oathtool and libpath (and ubuntu builds pam) just fine.  But it doesn’t build any pskc artifacts…I believe it’s because the configure script doesn’t find libxml2…so it never attempts to run configure
 in libpskc and pskctool.
 
So there is no “build error” to see…the error is that it’s not building the requested pskc artifacts…how to build these when it can’t locate libxml2 ?
 
I believe our Yocto ARM build was taken directly from the OpenEmbedded repository, and is an older version (oath 2.6.2), but it is broken in regards to pskc artifacts also. We tried replacing it with the newsest
 version, but it too has the same problem.
 
Hope this helps.
 
 

From:
Simon Josefsson 
Date: Monday, July 24, 2023 at 11:54 AM
To: Joseph Cossette 
Cc: oath-toolkit-help@nongnu.org 
Subject: Re: Build issues

Hi

 


Can you qoute the build error you get from “make”? You need libxmlsec, did you use the commands suggested here:


 


















CONTRIBUTING.md
 · master · oath-toolkit / oath-toolkit · GitLab
gitlab.com












 

In particular: 


apt-get install make git autoconf automake libtool bison gengetopt valgrind apt-get install libpam0g-dev libxmlsec1-dev libxml2-utils apt-get install help2man gtk-doc-tools libglib2.0-dev dblatex


 


/Simon







24 juli 2023 kl. 17:46 skrev Joseph Cossette :




 
Sure.
 
I created a VM from standard desktop Ubuntu 22.04.2 LTS .iso file.  Added build essentials and some other tools for development, as well as any other noted dependencies for oath toolkit (Linux pam headers,
 libxml2, etc.,…).
 
Used the following command line to configure:
 
/configure --prefix=$PWD/../built --enable-pskc

 
Configure ends with the following lines, which show that pskc would not be built:
 
  version:  2.6.9
  Install prefix:   /mnt/hgfs/snc2/third_party/oath/oath-toolkit-2.6.9/../built
  Compiler: gcc
  Build PAM module: yes
  PSKC: no
 
I’ve attached the config.log & config.status file for your perusal.  In searching for XML2 in the config log file it appears to indicate that it didn’t find it, even though it is installed on the system. 
 It then of course doesn’t even attempt to build any pskc artifacts, as where if it at least configured for pskc artifacts the resolution could then be deferred to compilation/linking steps, which is typically easier to handle for embedded systems.
 
As I previously mentioned, oathtool and it’s dependent library liboath appear to be building correctly for both Ubuntu and Yocto ARM.  But whenever we try to build the pskc artifacts by enabling them to configure,
 we basically get the same thing on both systems…namely, configure appears to not find the libxml2 artifacts. No pskc artifacts, only oath artifacts get produced.  Our Yocto build is also not building the pam module.  Since we’re also building the kernel in
 the Yocto sandbox it successfully builds all other pams though.
 
I’m sure if we put more man hours into it we could come up with a custom CMake build for this package within our Yocto sandbox, but we would much prefer to use your standard build so as to be able to get any
 timely security fixes and testcases.  But since it appeared that there may be a build problem with the package even using a popular standard desktop Linux,  I thought we’d wait before we spin any more resources and see if you folks had any ideas before we
 proceeded further.
 
Any help in getting this built using your standard build package would be greatly appreciated.

 
Thanks in advance.
 
 
 
 
On 7/21/23, 7:35 PM, "Simon Josefsson"  wrote:

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


 


The latest release 2.6.9 builds in many environ

Re: Build issues

2023-07-21 Thread Simon Josefsson via OATH Toolkit general discussions

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

The latest release 2.6.9 builds in many environments:

https://gitlab.com/oath-toolkit/oath-toolkit/-/pipelines/925626986

I maintain the Debian packages for it, which are also updated and
appears to build on all architectures:

https://tracker.debian.org/pkg/oath-toolkit

Including cross-builds:

http://crossqa.debian.net/src/oath-toolkit

/Simon

Joseph Cossette  writes:

> We’d like to use the oath toolkit for 2FA on our new embedded device,
> but we’re having issues trying to get it all built under Yocto (or
> Ubuntu 22.04 desktop for that matter).
>
> We’re able to get oathtool and liboath built (and on Ubuntu also the pam).
>
> But pskctool and libpskc refuse to be configured.  After examination
> it appears that XML2 may be the cause of the problem (even under
> Ubuntu).  XML2 is installed in Yocto (and Ubuntu), but the configure
> check for the package always fails, so it’s not being included in the
> makefiles (on both platforms).
>
> I did a bit of searching and saw that a 2-year old merge ticket on
> XML2 was put in by folks here…it mentions 2.70+…we’re using 2.9.x
> versions…but configure still doesn’t find them.
>
> It appears (for all practical purposes), the oath toolkit configure
> procedure is broken…likely on many systems too if it can’t even be
> built out of the box on Ubuntu 22.04.
>
> Not sure where to go from here on this.  We’ve already put in quite a
> few man hours into trying to get this built and have stopped trying at
> this point…it’s burning up too much resources…;(…
>
> If anyone has any information on how to resolve this issue please reply.


signature.asc
Description: PGP signature

OATH Toolkit 2.6.9

2023-07-09 Thread Simon Josefsson via OATH Toolkit general discussions

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 Container (PSKC, RFC 6030) to manage secret key
data.  OATH stands for Open AuTHentication, which is the organization
that specify the algorithms.

The following components are included:

 * liboath: A shared and static C library for OATH handling.
 * oathtool: A command line tool for generating and validating OTPs.
 * pam_oath: A PAM module for pluggable login authentication for OATH.
 * libpskc: A shared and static C library for PSKC handling.
 * pskctool: A command line tool for manipulating PSKC data.

The project's web page is available at:
  https://www.nongnu.org/oath-toolkit/

Documentation for the command line tools oathtool and pskctool:
  https://www.nongnu.org/oath-toolkit/oathtool.1.html
  https://www.nongnu.org/oath-toolkit/pskctool.1.html

Tutorial on PSKC:
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial.html

Manual for PAM module:
  https://www.nongnu.org/oath-toolkit/pam_oath.html

Liboath Manual:
  https://www.nongnu.org/oath-toolkit/liboath-api/liboath-oath.h.html

Libpskc Manual
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-reference.html

General information on contributing:
  https://www.nongnu.org/oath-toolkit/contrib.html

OATH Toolkit GitLab project page:
  https://gitlab.com/oath-toolkit/oath-toolkit

OATH Toolkit Savannah project page:
  https://savannah.nongnu.org/projects/oath-toolkit/

Code coverage charts:
  https://oath-toolkit.gitlab.io/oath-toolkit/coverage/

Clang code analysis:
  https://oath-toolkit.gitlab.io/oath-toolkit/clang-analyzer/

If you need help to use the OATH Toolkit, or want to help others, you
are invited to join our oath-toolkit-help mailing list, see:
  https://lists.nongnu.org/mailman/listinfo/oath-toolkit-help

Here are the compressed sources and a GPG detached signature:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.9.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.9.tar.gz.sig

Here are the SHA1 and SHA224 checksums:

f2c6d1d7c152aec9ec13e5d4dcc9fb1669c8014c  oath-toolkit-2.6.9.tar.gz
3397c028d64273537e0e372d18c4bb65a6e6f850266b1bb52067f347  
oath-toolkit-2.6.9.tar.gz

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify oath-toolkit-2.6.9.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key si...@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- https://josefsson.org/key-20190320.txt | gpg --import

NEWS

* Version 2.6.9 (released 2023-07-09)

** Improve compatibility with recent libxmlsec.

** Update gnulib files, dropping gnulib self-tests.

Happy hacking,
Simon


signature.asc
Description: PGP signature

OATH Toolkit 2.6.8

2023-07-08 Thread Simon Josefsson via OATH Toolkit general discussions

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 Container (PSKC, RFC 6030) to manage secret key
data.  OATH stands for Open AuTHentication, which is the organization
that specify the algorithms.

The following components are included:

 * liboath: A shared and static C library for OATH handling.
 * oathtool: A command line tool for generating and validating OTPs.
 * pam_oath: A PAM module for pluggable login authentication for OATH.
 * libpskc: A shared and static C library for PSKC handling.
 * pskctool: A command line tool for manipulating PSKC data.

The project's web page is available at:
  https://www.nongnu.org/oath-toolkit/

Documentation for the command line tools oathtool and pskctool:
  https://www.nongnu.org/oath-toolkit/oathtool.1.html
  https://www.nongnu.org/oath-toolkit/pskctool.1.html

Tutorial on PSKC:
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial.html

Manual for PAM module:
  https://www.nongnu.org/oath-toolkit/pam_oath.html

Liboath Manual:
  https://www.nongnu.org/oath-toolkit/liboath-api/liboath-oath.h.html

Libpskc Manual
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-reference.html

General information on contributing:
  https://www.nongnu.org/oath-toolkit/contrib.html

OATH Toolkit GitLab project page:
  https://gitlab.com/oath-toolkit/oath-toolkit

OATH Toolkit Savannah project page:
  https://savannah.nongnu.org/projects/oath-toolkit/

Code coverage charts:
  https://oath-toolkit.gitlab.io/oath-toolkit/coverage/

Clang code analysis:
  https://oath-toolkit.gitlab.io/oath-toolkit/clang-analyzer/

If you need help to use the OATH Toolkit, or want to help others, you
are invited to join our oath-toolkit-help mailing list, see:
  https://lists.nongnu.org/mailman/listinfo/oath-toolkit-help

Here are the compressed sources and a GPG detached signature:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.8.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.8.tar.gz.sig

Here are the SHA1 and SHA224 checksums:

139e535dfb51016d37a3afebfcd9d00d14c47ed4  oath-toolkit-2.6.8.tar.gz
d2788564f388b04a5e60fcf737b158470f723bca73011af51d238c1e  
oath-toolkit-2.6.8.tar.gz

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify oath-toolkit-2.6.8.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key si...@josefsson.org

  gpg --recv-keys 51722B08FE4745A2

  wget -q -O- https://josefsson.org/key-20190320.txt | gpg --import

NEWS

* Version 2.6.8 (released 2023-07-09)

** libpskc: Fixes for recent libxmlsec releases.

** pam_oath: Provide fallback pam_modutil_getpwnam implementation.
Fixes  on
Mac OS.  Patch from Nick Gaya .

** pam_oath: Don't fail authentication when pam_modutil_getpwnam doesn't
** know the user when usersfile don't include ${USER} or ${HOME}. Closes: #27.
Regression introduced in previous release.  Reported by Nick Gaya
.

** pam_oath: Self-test improvements.
Patch from Nick Gaya .

** liboath: Builds on Windows.
The oath_authenticate_usersfile function is just a stub that returns
an error.  This allows for use of the rest of the library on Windows.
Thanks to David Woodhouse, see
.

** Disable PAM self-tests on Mac.  Fix --enable-root-tests logic.

** Don't ship gtk-doc PDF's in tarball.

** Use gitlog-to-changelog instead of git2cl.

** Codespell typo fixes.
Patch by Dimitri Papadopoulos.

Happy hacking,
Simon


signature.asc
Description: PGP signature

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

2022-11-13 Thread Simon Josefsson via OATH Toolkit general discussions

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 'gdoc'
was missing but it is part of the git repo.  If you can reproduce it, we
should fix that and add a regression test to CI/CD.  I'm sure there are
many build-variants that aren't fully tested right now.

/Simon

signature.asc
Description: PGP signature

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

2022-11-12 Thread Simon Josefsson via OATH Toolkit general discussions

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

https://gitlab.com/oath-toolkit/oath-toolkit/-/commit/0ae59b9c72f69ee21044e736e292b73051df3272

/Simon



signature.asc
Description: PGP signature

OATH Toolkit 2.6.7

2021-05-01 Thread Simon Josefsson via OATH Toolkit general discussions

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 in usersfile string parameter.
These changes introduce the ${USER} and ${HOME} placeholder values for
the usersfile string in the pam_oath configuration file. The
placeholder values allow the user credentials file to be stored in a
file path that is relative to the user, and mimics similar behavior
found in google-authenticator-libpam.

The motivation for these changes is to allow for non-privileged
processes to use pam_oath (e.g., for 2FA with
xscreensaver). Non-privileged and non-suid programs are unable to use
pam_oath. These changes are a proposed alternative to a suid helper
binary as well.

Thanks to Jason Graham  for the patch.  See
.

** doc: Fix project URL in man pages.
Thanks to Jason Graham  for the patch.  Fixes
.

** build: Drop use of libxml's AM_PATH_XML2 in favor of pkg-config.

** build: Modernize autotools usage.
Most importantly, no longer use -Werror with AM_INIT_AUTOMAKE to make
rebuilding from source more safe with future automake versions.

** Updated gnulib files.

Happy hacking,
Simon

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 Container (PSKC, RFC 6030) to
manage secret key data.  OATH stands for Open AuTHentication, which is
the organization that specify the algorithms.

The components included in the package is:

  * liboath: A shared and static C library for OATH handling.

  * oathtool: A command line tool for generating and validating OTPs.

  * pam_oath: A PAM module for pluggable login authentication for OATH.

  * libpskc: A shared and static C library for PSKC handling.

  * pskctool: A command line tool for manipulating PSKC data.

The project's web page is available at:
  https://www.nongnu.org/oath-toolkit/

Documentation for the command line tools oathtool and pskctool:
  https://www.nongnu.org/oath-toolkit/oathtool.1.html
  https://www.nongnu.org/oath-toolkit/pskctool.1.html

Tutorial on PSKC:
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial.html

Manual for PAM module:
  https://www.nongnu.org/oath-toolkit/pam_oath.html

Liboath Manual:
  https://www.nongnu.org/oath-toolkit/liboath-api/liboath-oath.h.html

Libpskc Manual
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-reference.html

If you need help to use the OATH Toolkit, or want to help others, you
are invited to join our oath-toolkit-help mailing list, see:
  https://lists.nongnu.org/mailman/listinfo/oath-toolkit-help

Here are the compressed sources of the entire package:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.7.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.7.tar.gz.sig

The software is cryptographically signed by the author using an OpenPGP
key identified by the following information:

pub   ed25519 2019-03-20 [SC]
  B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
uid   [ultimate] Simon Josefsson 

The key is available from:
  https://josefsson.org/key-20190320.txt

I have changed key since older releases, see my transition statements:
  https://blog.josefsson.org/2019/03/21/openpgp-2019-key-transition-statement/
  https://blog.josefsson.org/2014/06/23/openpgp-key-transition-statement/

Here are the SHA-1 and SHA-224 checksums:

43daea1daab55ff3d5282fdcaec5f23764ff8fb4  oath-toolkit-2.6.7.tar.gz
5d828599959a198aa6e4bd716af59d6f74ea56bc89c9947f6323fa8c  
oath-toolkit-2.6.7.tar.gz

General information on contributing:
  https://www.nongnu.org/oath-toolkit/contrib.html

OATH Toolkit GitLab project page:
  https://gitlab.com/oath-toolkit/oath-toolkit

OATH Toolkit Savannah project page:
  https://savannah.nongnu.org/projects/oath-toolkit/

Code coverage charts:
  https://oath-toolkit.gitlab.io/oath-toolkit/coverage/

Clang code analysis:
  https://oath-toolkit.gitlab.io/oath-toolkit/clang-analyzer/


signature.asc
Description: PGP signature

Re: libpskc 2.6.6 test-sute.log

2021-05-01 Thread Simon Josefsson via OATH Toolkit general discussions

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 out some calls, causing unpredictable stacktraces.
Tracking down why the memory leak happens is of course very welcome.

/Simon


signature.asc
Description: PGP signature

Re: oathtool make target without for API manuals?

2021-04-15 Thread Simon Josefsson via OATH Toolkit general discussions

"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 instructions.
>> Normally you unpack the tarball, invoke ./configure and then make.
>> Anything else is not a normal installation, and to run autoreconf you
>> need the developer tools (see HACKING).
>
> Thanks! Yes the issue was wholly with some odd choices Pkgsrc have
> made. I had stupidly tried first building from git master (i.e. no
> prebuilt configure file) but building from the tarball source works
> first try.
>
> I've submitted a patch to Pkgsrc to hopefully clean up their Makefile.
>
> Thanks for all your help.

Thank you for helping packaging oath-toolkit!  Whether to build from
tarballs or version controlled sources, and whether to attempt to
re-bootstrap the sources using autoreconf or not, can be controversial
decisions in some projects.  I don't care strongly, but right now
gtk-doc is optional for tarballs but required when building from
sources.  Improving that is welcome, but IMHO should be done through the
gtk-doc-tools project so we don't introduce a new set of bugs.

/Simon

signature.asc
Description: PGP signature

Re: oathtool make target without for API manuals?

2021-04-14 Thread Simon Josefsson via OATH Toolkit general discussions

"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 using Pkgsrc, so it was as easy as
>>> adding
>>> 
>>> DISTCHECK_CONFIGURE_FLAGS=
>>> 
>>> to the Pkgsrc Makefile. I just had trouble finding that variable
>>> before in the source. Everything builds without gtk-doc.
>> 
>> Okay great.  That variable is only used if you invoke 'make distcheck'
>> which for a normal installation isn't something you need to do.
>
> Oh wait, I'm sorry I spoke too soon! Looks like I was building with gtk-doc 
> still installed. Once actually removed, I can no longer build. I've tried 
> these:
>
>   DISTCHECK_CONFIGURE_FLAGS=
>   CFGFLAGS= 
>
> When building with Pkgsrc, build fails at:
>
>
> ```
> cd
> /Users/pwr/Developer/pkgsrc/security/oath-toolkit/work/oath-toolkit-2.4.1
> && autoreconf -fi

Why invoke autoreconf?  Read INSTALL for installation instructions.
Normally you unpack the tarball, invoke ./configure and then make.
Anything else is not a normal installation, and to run autoreconf you
need the developer tools (see HACKING).

/Simon


> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
>   
> 
> libtoolize: copying file 'build-aux/ltmain.sh'
>   
> 
> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. 
>   
>
> libtoolize: copying file 'm4/libtool.m4'  
>   
> 
> libtoolize: copying file 'm4/ltoptions.m4'
>   
> 
> libtoolize: copying file 'm4/ltsugar.m4'  
>   
> 
> libtoolize: copying file 'm4/ltversion.m4'
>   
> 
> libtoolize: copying file 'm4/lt~obsolete.m4'  
>   
> 
> Can't exec "gtkdocize": No such file or directory at 
> /usr/local/pkg/share/autoconf/Autom4te/FileUtils.pm line 293. 
> 
> autoreconf: error: gtkdocize failed with exit status: 2   
>   
>
> *** Error code 2  
>   
> 
>   
>   
>
> Stop. 
>   
>
> ```
>
>
> When attempting gmake from Pkgsrc's "work" directory:
>
>
> ```
> gmake CFGFLAGS=
> [...]
> configure: summary of build options:
>
>   version:  2.4.1
>   Install prefix:   /usr/local
>   Compiler: gcc
>   Build PAM module: yes
>   PSKC: no
>
> make
>  cd . && /bin/sh 
> /Users/pwr/Developer/pkgsrc/security/oath-toolkit/work/oath-toolkit-2.4.1/build-aux/missing
>  automake-1.14 --gnu
> /Users/pwr/Developer/pkgsrc/security/oath-toolkit/work/oath-toolkit-2.4.1/build-aux/missing:
>  line 81: automake-1.14: command not found
> WARNING: 'automake-1.14' is missing on your system.
>  You should only need it if you modified 'Makefile.am' or
>  'configure.ac' or m4 files included by 'configure.ac'.
>  The 'automake' program is part of the GNU Automake package:
>  
>  It also requires GNU Autoconf, GNU m4 and Perl in

Re: oathtool make target without for API manuals?

2021-04-13 Thread Simon Josefsson via OATH Toolkit general discussions

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:
> > 
> > https://gitlab.com/oath-toolkit/oath-toolkit/-/jobs/1083520652
> > 
> > What is the build failure you got?
> 
> Thanks Simon! No build failure here, I just wanted to avoid the gtk-
> doc dependencies. I'm on macOS using Pkgsrc, so it was as easy as
> adding
> 
>   DISTCHECK_CONFIGURE_FLAGS=
> 
> to the Pkgsrc Makefile. I just had trouble finding that variable
> before in the source. Everything builds without gtk-doc.

Okay great.  That variable is only used if you invoke 'make distcheck'
which for a normal installation isn't something you need to do.

/Simon


signature.asc
Description: This is a digitally signed message part

Re: oathtool make target without for API manuals?

2021-04-12 Thread Simon Josefsson via OATH Toolkit general discussions

"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 the CI/CD continously builds it on
CentOS7 without gtk-doc installed, see latest build here:

https://gitlab.com/oath-toolkit/oath-toolkit/-/jobs/1083520652

What is the build failure you got?

/Simon

signature.asc
Description: PGP signature

OATH Toolkit 2.6.5

2020-12-30 Thread Simon Josefsson via OATH Toolkit general discussions

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 @FILE to read
from a particular file.  This is recommended on multi-user systems,
since secrets as command line parameters leak.  Based on a patch from
Ian Jackson .  Fixes #6.

** pam_oath: Fix unlikely logic fail on out of memory conditions.
Patch from Matthias Gerstner.

** Doc fixes.

Happy hacking,
Simon

The OATH Toolkit makes it easy to build one-time password authentication
systems.  It contains shared libraries, command line tools and a PAM
module.  Supported technologies include the event-based HOTP algorithm
(RFC4226) and the time-based TOTP algorithm (RFC6238).  OATH stands for
Open AuTHentication, which is the organization that specify the
algorithms.  For managing secret key files, the Portable Symmetric Key
Container (PSKC) format described in RFC6030 is supported.

The components included in the package is:

  * liboath: A shared and static C library for OATH handling.

  * oathtool: A command line tool for generating and validating OTPs.

  * pam_oath: A PAM module for pluggable login authentication for OATH.

  * libpskc: A shared and static C library for PSKC handling.

  * pskctool: A command line tool for manipulating PSKC data.

The project's web page is available at:
  https://www.nongnu.org/oath-toolkit/

Documentation for the command line tools oathtool and pskctool:
  https://www.nongnu.org/oath-toolkit/oathtool.1.html
  https://www.nongnu.org/oath-toolkit/pskctool.1.html
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial-pskctool.html

Manual for PAM module:
  https://www.nongnu.org/oath-toolkit/pam_oath.html

Liboath Manual:
  https://www.nongnu.org/oath-toolkit/liboath-api/liboath-oath.html

Libpskc Manual
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-reference.html

If you need help to use the OATH Toolkit, or want to help others, you
are invited to join our oath-toolkit-help mailing list, see:
  https://lists.nongnu.org/mailman/listinfo/oath-toolkit-help

Here are the compressed sources of the entire package:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.5.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.5.tar.gz.sig

The software is cryptographically signed by the author using an OpenPGP
key identified by the following information:

pub   ed25519 2019-03-20 [SC]
  B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
uid   [ultimate] Simon Josefsson 

The key is available from:
  https://josefsson.org/key-20190320.txt

I have changed key since older releases, see my transition statement:
  https://blog.josefsson.org/2019/03/21/openpgp-2019-key-transition-statement/
  https://blog.josefsson.org/2014/06/23/openpgp-key-transition-statement/

Here are the SHA-1 and SHA-224 checksums:

31eff0b9bcc4dd5f397b9abc0cf2ccdb99615c9e  oath-toolkit-2.6.5.tar.gz
5dd716a98749ba22bfe5fa8597f8b6ee7a01dda744ec3ee462ffd3e2  
oath-toolkit-2.6.5.tar.gz

General information on contributing:
  https://www.nongnu.org/oath-toolkit/contrib.html

OATH Toolkit GitLab project page:
  https://gitlab.com/oath-toolkit/oath-toolkit

OATH Toolkit Savannah project page:
  https://savannah.nongnu.org/projects/oath-toolkit/

Code coverage charts:
  https://oath-toolkit.gitlab.io/oath-toolkit/coverage/

Clang code analysis:
  https://oath-toolkit.gitlab.io/oath-toolkit/clang-analyzer/



signature.asc
Description: PGP signature

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

2020-12-27 Thread Simon Josefsson via OATH Toolkit general discussions

tags 839278 +upstream
tags 839278 +fixed-upstream
tags 839278 +confirmed
thanks

Ian Jackson  writes:

>> If someone wants to add support for reading from a numbered file
>> descriptor, I'm happy to merge that -- how about '*42'?  Just don't pick
>> a character that is in the base64 alphabet (right now only hex and
>> base32 are supported, but maybe base64 support will be added in the
>> future).  The '*' character would work.  Is this useful though?
>
> On many operating systems @/dev/fd/N would work nicely.

Indeed!  This appears to work:

jas@latte:~/src/oath-toolkit$ echo 00 | oathtool/oathtool @/dev/stdin
328482
jas@latte:~/src/oath-toolkit$ echo 00 | oathtool/oathtool @/dev/fd/0
328482
jas@latte:~/src/oath-toolkit$ 

I am confused why this works though:

jas@latte:~/src/oath-toolkit$ oathtool/oathtool @/dev/fd/1
00   <-- I type `00 RET' in the terminal
328482
jas@latte:~/src/oath-toolkit$ oathtool/oathtool @/dev/fd/2
00   <-- I type `00 RET' in the terminal
328482
jas@latte:~/src/oath-toolkit$ 

Thoughts?  Reading from stdout or stderr seems weird, but I don't know
what to expect.  For what it's worth, `cat' behaves the same.

As expected non-open file descriptors yield an error:

jas@latte:~/src/oath-toolkit$ oathtool/oathtool @/dev/fd/3
oathtool: open file for KEY/OTP: No such file or directory
jas@latte:~/src/oath-toolkit$ 

/Simon


signature.asc
Description: PGP signature

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

2020-12-26 Thread Simon Josefsson via OATH Toolkit general discussions

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
>> 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.
>
> '@filename' would be somewhat common, I think.

I have pushed Ian's patch, but I dropped his newly introduced
command-line parameter and instead allowed for KEY and OTP parameters to
be - to mean stdin or @filename like you suggested Ilkka.

A string of '-' is not valid hex, base32 or base64, and @filename is not
valid hex, base32 or base64 either.

If someone wants to add support for reading from a numbered file
descriptor, I'm happy to merge that -- how about '*42'?  Just don't pick
a character that is in the base64 alphabet (right now only hex and
base32 are supported, but maybe base64 support will be added in the
future).  The '*' character would work.  Is this useful though?

https://gitlab.com/oath-toolkit/oath-toolkit/-/commit/56f28bde2059ebb87fead40fb371168ee44d840c

/Simon

signature.asc
Description: PGP signature

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

2020-11-12 Thread Simon Josefsson via OATH Toolkit general discussions

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

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:

https://github.com/tadfisher/pass-otp
https://github.com/matalo33/py_oathtool

/Simon

signature.asc
Description: PGP signature

Bug#971441: Package not built from source: gengetopt

2020-11-12 Thread Simon Josefsson via OATH Toolkit general discussions

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

OATH Toolkit 2.6.4

2020-11-11 Thread Simon Josefsson via OATH Toolkit general discussions

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 dynamic loading
fails because of runtime linker search path issues.

** oathtool --totp --verbose now prints TOTP hash mode.
Fixes .

** oathtool: Hash names (e.g., SHA256) for --totp are now upper case.
Fixes .
Lower/mixed case hash names are supported for compatibility.

** pam_oath: Fail gracefully for missing users.
Fixes .
This allows you to incrementally add support for OATH authentication
instead of forcing it on all users.  See updated pam_oath/README on
the '[user_unknown=ignore success=ok]' parameter that can now be
supplied to PAM configuration.  Patch by Antoine Beaupré
.

** Fix libpskc memory corruption bug.
Fixes .  Thanks to David
Woodhouse and Jaroslav Škarvada for report, self check and patch.

** Fix man pages.
Fixes .  Thanks to
Jaroslav Škarvada for the patch.

** Build fixes.

Happy hacking,
Simon

The OATH Toolkit makes it easy to build one-time password authentication
systems.  It contains shared libraries, command line tools and a PAM
module.  Supported technologies include the event-based HOTP algorithm
(RFC4226) and the time-based TOTP algorithm (RFC6238).  OATH stands for
Open AuTHentication, which is the organization that specify the
algorithms.  For managing secret key files, the Portable Symmetric Key
Container (PSKC) format described in RFC6030 is supported.

The components included in the package is:

  * liboath: A shared and static C library for OATH handling.

  * oathtool: A command line tool for generating and validating OTPs.

  * pam_oath: A PAM module for pluggable login authentication for OATH.

  * libpskc: A shared and static C library for PSKC handling.

  * pskctool: A command line tool for manipulating PSKC data.

The project's web page is available at:
  https://www.nongnu.org/oath-toolkit/

Documentation for the command line tools oathtool and pskctool:
  https://www.nongnu.org/oath-toolkit/oathtool.1.html
  https://www.nongnu.org/oath-toolkit/pskctool.1.html
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial-pskctool.html

Manual for PAM module:
  https://www.nongnu.org/oath-toolkit/pam_oath.html

Liboath Manual:
  https://www.nongnu.org/oath-toolkit/liboath-api/liboath-oath.html

Libpskc Manual
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-reference.html

If you need help to use the OATH Toolkit, or want to help others, you
are invited to join our oath-toolkit-help mailing list, see:
  https://lists.nongnu.org/mailman/listinfo/oath-toolkit-help

Here are the compressed sources of the entire package:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.4.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.4.tar.gz.sig

The software is cryptographically signed by the author using an OpenPGP
key identified by the following information:

pub   ed25519 2019-03-20 [SC] [expires: 2021-01-24]
  B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
uid   [ultimate] Simon Josefsson 

The key is available from:
  https://josefsson.org/key-20190320.txt

I have changed key since older releases, see my transition statement:
  https://blog.josefsson.org/2019/03/21/openpgp-2019-key-transition-statement/
  https://blog.josefsson.org/2014/06/23/openpgp-key-transition-statement/

Here are the SHA-1 and SHA-224 checksums:

bb3784c8e32cd3be2b2b95d1ed53607fbbe23200  oath-toolkit-2.6.4.tar.gz
316f359eb8616b23a48593f281d5b1d88874d307dd513b61c7eceda1  
oath-toolkit-2.6.4.tar.gz

General information on contributing:
  https://www.nongnu.org/oath-toolkit/contrib.html

OATH Toolkit GitLab project page:
  https://gitlab.com/oath-toolkit/oath-toolkit

OATH Toolkit Savannah project page:
  https://savannah.nongnu.org/projects/oath-toolkit/

Code coverage charts:
  https://oath-toolkit.gitlab.io/oath-toolkit/coverage/

Clang code analysis:
  https://oath-toolkit.gitlab.io/oath-toolkit/clang-analyzer/


signature.asc
Description: PGP signature

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

2020-11-11 Thread Simon Josefsson via OATH Toolkit general discussions

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 release yor pskctest.c [1] as
>> LGPLv2.1+
>> so I can include it as a self test to catch regressions?
>> 
>> [1] https://bugzilla.redhat.com/attachment.cgi?id=926222
>
> Sure. I've commented to that effect in the bug, for the record.

Thank you!  Merged and will be part of the next release.

/Simon


signature.asc
Description: PGP signature

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

2020-11-11 Thread Simon Josefsson via OATH Toolkit general discussions

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 release yor pskctest.c [1] as LGPLv2.1+
so I can include it as a self test to catch regressions?

[1] https://bugzilla.redhat.com/attachment.cgi?id=926222

Thanks,
/Simon

signature.asc
Description: PGP signature

Bug#971440: Fixes for upstream build problems

2020-11-08 Thread Simon Josefsson via OATH Toolkit general discussions

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 [OTP]" \

I solved this slightly differently, see:

https://gitlab.com/oath-toolkit/oath-toolkit/-/commit/fa2237f9b47c57dc3e78a90abe381e64be98a08d

> This asprintf call has only one %s.  Both arguments are the same
> string - that has just been checked.  So delete the 2nd.

Looks like I already fixed this one myself.

/Simon


signature.asc
Description: PGP signature

Re: wrong package description

2020-11-08 Thread Simon Josefsson via OATH Toolkit general discussions

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' contains a PAM module, which is true.  The first
paragraph describe the upstream project, and the second paragraph
explains what is included in the particular Debian package.

/Simon

signature.asc
Description: PGP signature

Re: Annoyance with examples in online manual

2020-11-08 Thread Simon Josefsson via OATH Toolkit general discussions

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 like "oathtool: hex
> decoding of secret key failed”.
>
> This is because on the web page the dashes in arguments such as
> “—totp” are actually unicode minus signs, U+2212, instead of ASCII
> dash (0x2d) which is what the program expects.
>
> PS: the same problem occurs in the email address for
> oath-toolkit-help@nongnu.org  at
> the bottom of that page.

Hi Tim!  Thanks for the report.  Version 2.6.3 was just released, and
those pages were re-generated using modern tools, and the pages appear
to contains real ASCII '--' now.  Can you confirm this?  Maybe it
depends on the browser, but at least inspecting the HTML code now
suggests it should really be fixed.

/Simon

signature.asc
Description: PGP signature

Re: verification error

2020-11-08 Thread Simon Josefsson via OATH Toolkit general discussions

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, it contains newer gnulib which
should hopefully work on recent Mac OS.

/Simon

signature.asc
Description: PGP signature

OATH Toolkit 2.6.3

2020-11-08 Thread Simon Josefsson via OATH Toolkit general discussions

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 been missing and help me update any merge requests
so they can be more easily reviewed.

Happy hacking,
Simon

The OATH Toolkit makes it easy to build one-time password authentication
systems.  It contains shared libraries, command line tools and a PAM
module.  Supported technologies include the event-based HOTP algorithm
(RFC4226) and the time-based TOTP algorithm (RFC6238).  OATH stands for
Open AuTHentication, which is the organization that specify the
algorithms.  For managing secret key files, the Portable Symmetric Key
Container (PSKC) format described in RFC6030 is supported.

The components included in the package is:

  * liboath: A shared and static C library for OATH handling.

  * oathtool: A command line tool for generating and validating OTPs.

  * pam_oath: A PAM module for pluggable login authentication for OATH.

  * libpskc: A shared and static C library for PSKC handling.

  * pskctool: A command line tool for manipulating PSKC data.

The project's web page is available at:
  https://www.nongnu.org/oath-toolkit/

Documentation for the command line tools oathtool and pskctool:
  https://www.nongnu.org/oath-toolkit/oathtool.1.html
  https://www.nongnu.org/oath-toolkit/pskctool.1.html
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial-pskctool.html

Manual for PAM module:
  https://www.nongnu.org/oath-toolkit/pam_oath.html

Liboath Manual:
  https://www.nongnu.org/oath-toolkit/liboath-api/liboath-oath.html

Libpskc Manual
  https://www.nongnu.org/oath-toolkit/libpskc-api/pskc-reference.html

If you need help to use the OATH Toolkit, or want to help others, you
are invited to join our oath-toolkit-help mailing list, see:
  https://lists.nongnu.org/mailman/listinfo/oath-toolkit-help

Here are the compressed sources of the entire package:
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.3.tar.gz
  
https://download.savannah.nongnu.org/releases/oath-toolkit/oath-toolkit-2.6.3.tar.gz.sig

The software is cryptographically signed by the author using an OpenPGP
key identified by the following information:

pub   ed25519 2019-03-20 [SC] [expires: 2021-01-24]
  B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
uid   [ultimate] Simon Josefsson 

The key is available from:
  https://josefsson.org/key-20190320.txt

I have changed key since older releases, see my transition statement:
  https://blog.josefsson.org/2019/03/21/openpgp-2019-key-transition-statement/
  http://blog.josefsson.org/2014/06/23/openpgp-key-transition-statement/

Here are the SHA-1 and SHA-224 checksums:

27a75c35834292adc8d925d6c7d024f5f3b9215d  oath-toolkit-2.6.3.tar.gz
47fa1f8a654b12930d01e292c0e8a0fbc8bb65f82dde7cd9e624730f  
oath-toolkit-2.6.3.tar.gz

General information on contributing:
  https://www.nongnu.org/oath-toolkit/contrib.html

GitLab's page:
  https://gitlab.com/oath-toolkit/oath-toolkit

Savannah developer's home page:
  https://savannah.nongnu.org/projects/oath-toolkit/

Code coverage charts:
  https://www.nongnu.org/oath-toolkit/coverage/

Clang code analysis:
  https://www.nongnu.org/oath-toolkit/clang-analyzer/


signature.asc
Description: PGP signature

OATH Toolkit 2.6.12

[SECURITY ADVISORY] oath-toolkit: pam_oath usersfile ${HOME} privilege escalation

Re: pam_oath with user_unknown=ignore

Re: pam_oath with user_unknown=ignore

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

OATH Toolkit 2.6.11

OATH Toolkit 2.6.10

Re: SHA384

Re: SHA384

Re: Build issues

Re: Build issues

Re: Build issues

OATH Toolkit 2.6.9

OATH Toolkit 2.6.8

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

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

OATH Toolkit 2.6.7

Re: libpskc 2.6.6 test-sute.log

Re: oathtool make target without for API manuals?

Re: oathtool make target without for API manuals?

Re: oathtool make target without for API manuals?

Re: oathtool make target without for API manuals?

OATH Toolkit 2.6.5

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

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

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

Bug#971441: Package not built from source: gengetopt

OATH Toolkit 2.6.4

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

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

Bug#971440: Fixes for upstream build problems

Re: wrong package description

Re: Annoyance with examples in online manual

Re: verification error

OATH Toolkit 2.6.3

35 matches

Site Navigation

Mail list logo

Footer information