Bug#1062896: shishi: NMU diff for 64-bit time_t transition
reopen 1062896
thanks
Benjamin Drung writes:
> Source: shishi
> 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 working on this.
I noticed that autopkgtest for 1.0.3-2.1 fails on i386:
https://ci.debian.net/packages/s/shishi/testing/i386/43439759/
It is time related:
100s PASS: gcc tests/gztime.c
100s Segmentation fault
Debugging this (with help from #debian-devel) led me down several chains
of discoveries. I believe that this package has enabled and assumes
64-bit time_t on all 32-bit platforms for a long time, including i386.
Look at how the old version before your changes behave:
jas@kaka:~$ podman run --arch=386 -it --rm debian:testing
root@78d65bc11b9f:/# cat /etc/apt/sources.list.d/debian.sources | sed 's,:
deb,: deb-src,' > /etc/apt/sources.list.d/src.sources
root@78d65bc11b9f:/# apt update
root@78d65bc11b9f:~# apt install libshishi-dev build-essential
Get:76 http://deb.debian.org/debian testing/main i386 libshishi-dev i386
1.0.3-2 [217 kB]
root@78d65bc11b9f:~# apt source shishi
root@78d65bc11b9f:~# cd shishi-1.0.3/
root@78d65bc11b9f:~/shishi-1.0.3# touch config.h
root@78d65bc11b9f:~/shishi-1.0.3# WORKDIR=.
root@78d65bc11b9f:~/shishi-1.0.3# gcc -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
-I$WORKDIR -Ilib/gl -D_GL_ATTRIBUTE_CONST= -DPACKAGE='"shishi"' -o $WORKDIR/foo
tests/gztime.c `pkg-config --cflags --libs shishi`
root@78d65bc11b9f:~/shishi-1.0.3# ./foo
root@78d65bc11b9f:~/shishi-1.0.3# gcc -I$WORKDIR -Ilib/gl
-D_GL_ATTRIBUTE_CONST= -DPACKAGE='"shishi"' -o $WORKDIR/foo tests/gztime.c
`pkg-config --cflags --libs shishi`
root@78d65bc11b9f:~/shishi-1.0.3# ./foo
Segmentation fault (core dumped)
root@78d65bc11b9f:~/shishi-1.0.3#
This suggests passing 32-bit time_t to this library break before your
change, and it breaks after your changes too. See earlier debci failure
for 1.0.3-2 without your t64 changes here that confirms this hypothesis:
https://ci.debian.net/packages/s/shishi/testing/i386/43917754/
So the library is 64-bit only even on 32-bit architectures, or at least
i386, I briefly compared build logs on armhf too.
You can re-run the snippet above on unstable instead, and you will see
it behaves the same for 1.0.3-2.1. So the t64 patches did not modify
any ABI at all.
As far as I understand, this means this package does not need any
t64-migration at all, and your NMU should be reverted. Do you agree?
Arguable the package header .h file should not use the time_t type since
the shared library ABI will only work if the application uses 64-bit
time_t, but on i386 the normal approach is to have 32-bit time_t. This
would be an upstream wishlist, it was suggested to replace time_t with
int64_t so that callers that pass 32-bit time_t would get automatically
extended, which is one solution.
/Simon
> Thanks!
>
>
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>
> diff -Nru shishi-1.0.3/debian/changelog shishi-1.0.3/debian/changelog
> --- shishi-1.0.3/debian/changelog 2024-01-30 16:09:13.0 +
> +++ shishi-1.0.3/debian/changelog 2024-02-29 15:52:14.0 +
> @@ -1,3 +1,10 @@
> +shishi (1.0.3-2.1) unstable; urgency=medium
> +
> + * Non-maintainer upload.
> + * Rename libraries for 64-bit time_t transition. Closes: #1062896
> +
> + -- Benjamin Drung Thu, 29 Feb 2024 15:52:14 +
> +
> shishi (1.0.3-2) unstable; urgency=medium
>
>[ Simon Josefsson ]
> diff -Nru shishi-1.0.3/debian/control shishi-1.0.3/debian/control
> --- shishi-1.0.3/debian/control 2024-01-30 15:57:25.0 +
> +++ shishi-1.0.3/debian/control 2024-02-29 15:52:14.0 +
> @@ -5,7 +5,7 @@
> Uploaders:
> Simon Josefsson ,
> Russ Allbery ,
> -Build-Depends:
> +Build-Depends: dpkg-dev (>= 1.22.5),
> debhelper-compat (= 13),
> libgcrypt-dev,
> libgnutls28-dev,
> @@ -25,7 +25,10 @@
> Homepage: https://www.gnu.org/software/shishi/
> Rules-Requires-Root: no
>
> -Package: libshishi0
> +Package: libshishi0t64
> +Provides: ${t64:Provides}
> +Replaces: libshishi0
> +Breaks: libshishi0 (<< ${source:Version})
> Section: libs
> Architecture: any
> Mu
Re: static code analysis report
Andrew Marlow writes: > Hello, > > Thank you Simon for the quick reply. I looked at the job and it uses a > command called scan-build. Where is that defined please? It is shipped in the 'clang-analyzer' rpm-package or 'clang-tools' deb-package. https://pkgs.org/search/?q=scan-build&on=files /Simon > On Thu, 11 Aug 2022 at 07:22, Simon Josefsson wrote: > >> Andrew Marlow writes: >> >> > I saw the announcement made about the latest release of GNU shishi and >> was >> > very interested to see the report at https://gsasl.gitlab.io/shishi >> > /clang-analyzer/. How was this report produced please? I would like to be >> > able to do something similar for the projects that I work on. >> >> Hi. Thanks for your interest. They are built by GitLab CI/CD, see >> build rule here: >> >> https://git.savannah.gnu.org/cgit/shishi.git/tree/.gitlab-ci.yml#n107 >> >> There is a mirror on GitLab of the project, where the CICD happens: >> >> https://gitlab.com/gsasl/shishi >> >> /Simon >> signature.asc Description: PGP signature
Re: static code analysis report
Andrew Marlow writes: > I saw the announcement made about the latest release of GNU shishi and was > very interested to see the report at https://gsasl.gitlab.io/shishi > /clang-analyzer/. How was this report produced please? I would like to be > able to do something similar for the projects that I work on. Hi. Thanks for your interest. They are built by GitLab CI/CD, see build rule here: https://git.savannah.gnu.org/cgit/shishi.git/tree/.gitlab-ci.yml#n107 There is a mirror on GitLab of the project, where the CICD happens: https://gitlab.com/gsasl/shishi /Simon signature.asc Description: PGP signature
shishi-1.0.3 released [stable]
Shishi implements the Kerberos network authentication system. Shishi can be used to authenticate users in distributed systems, and is most often used via GSS-API for SSH or via SASL for IMAP/POP3. The project's web page is available at: https://www.gnu.org/software/shishi/ All manuals are available from: https://www.gnu.org/software/shishi/manual/ Direct links to the manual: HTML: https://www.gnu.org/software/shishi/manual/shishi.html PDF: https://www.gnu.org/software/shishi/manual/shishi.pdf Direct links to the API Reference manual: HTML: https://www.gnu.org/software/shishi/reference/ PDF: https://www.gnu.org/software/shishi/reference/shishi.pdf For code coverage, cyclomatic code complexity charts and clang analyzer see: https://gsasl.gitlab.io/shishi/coverage/ https://gsasl.gitlab.io/shishi/cyclo/ https://gsasl.gitlab.io/shishi/clang-analyzer/ If you need help to use GNU SASL, or want to help others, you are invited to join our help-gsasl mailing list, see: https://lists.gnu.org/mailman/listinfo/help-shishi Here are the compressed sources and a GPG detached signature: https://ftpmirror.gnu.org/shishi/shishi-1.0.3.tar.gz https://ftpmirror.gnu.org/shishi/shishi-1.0.3.tar.gz.sig Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html Here are the SHA1 and SHA256 checksums: ba249b6f322d680cf198aa9171d6abe330628866 shishi-1.0.3.tar.gz lXmP/RLdAaT4jgMR7gPKSibly05ekFmkDk/E2fKRfpI shishi-1.0.3.tar.gz The SHA256 checksum is base64 encoded, instead of the hexadecimal encoding that most checksum tools default to. 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 shishi-1.0.3.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://savannah.gnu.org/project/release-gpgkeys.php?group=shishi&download=1' | gpg --import - As a last resort to find the key, you can try the official GNU keyring: wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify shishi-1.0.3.tar.gz.sig This release was bootstrapped with the following tools: Autoconf 2.71 Automake 1.16.5 Libtoolize 2.4.6 Gnulib v0.1-5359-g6ef9c3334 Makeinfo 6.7 Help2man 1.48.1 Gengetopt 2.23 Gtkdocize 1.33.1 Tar 1.34 Gzip 1.10 Bison 3.7.5 NEWS * Noteworthy changes in release 1.0.3 (2022-08-07) [stable] ** New header file shishi-version (included from shishi.h). Adds symbols SHISHI_VERSION_MAJOR, SHISHI_VERSION_MINOR, SHISHI_VERSION_PATCH and SHISHI_VERSION_NUMBER. ** Modernize build infrastructure. We now use gnulib's bootstrap. ** pam_shishi: Implement options 'debug', 'realm=', and 'principal='. By Mats Erik Andersson . ** Numerous other code cleanups, bug fixes, improved documentation, ** updated translations, and portability improvements. Happy hacking, Simon signature.asc Description: PGP signature
Re: shishi-NLS: e...@boldquot.po is broken
Mats Erik Andersson writes: > onsdag den 17 april 2013 klockan 21:11 skrev Mats Erik Andersson detta: >> tisdag den 16 april 2013 klockan 00:07 skrev Simon Josefsson detta: >> > > There should really be a test whether these locales exist, >> > > before creating the message templates. >> > >> > Building these files should not require locales at all. Perhaps there >> > is a genuine gettext-on-FreeBSD bug lurking here? Which gettext version >> > are you using? > > Bug found! Thanks for tracking this down! > The intermediary pipe-chained call > >## Rules-quot > >$(MSGFILTER) sed -f ` echo $lang | ...` > > is broken, because it depends on GNU Sed without saying so. That would be a gettext bug, I would think. I assume it should not require GNU sed to work. > Only changing 'sed' to 'gsed' in 'po/Rules-quot' after issuing > 'gmake autoreconf', is sufficient to build the checked out > source on FreeBSD 9.1. Observe, that 'GNU Make' is needed > for initial preparation and now also GNU Sed for NLS preparation, > but otherwise, BSD Make is sufficient for the build. Right, GNU make is needed for building from VC, although it shouldn't be required for building from tarballs. It seems sub-optimal for GNU sed to be required, if that can be avoided. > The probable failure of BSD Sed together with GNU Msgfilter > could possibly be identified by the following observation, > taken from sed(1) of FreeBSD: > >BUGS >Multibyte characters containing a byte with value 0x5C (ASCII '\') >may be incorrectly treated as line continuation characters in >arguments to the 'a', 'c', and 'i' commands. Multibyte characters >cannot be used as delimiters with the 's' and 'y' commands. > > Which mailing list would be appropriate for contributing > the noted dependency on GNU Sed? Msgfilter is part of gettext, so bug-gnu-gett...@gnu.org according to the manpage. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishi-NLS: e...@boldquot.po is broken
Mats Erik Andersson writes: > onsdag den 3 april 2013 klockan 01:23 skrev Simon Josefsson detta: >> Mats Erik Andersson writes: >> >> > Hello there, >> > >> > the imported file >> > >> >po/e...@boldquot.po >> > >> > is broken, because 176 msgid/msgstr pairs are not >> > agreeing on the use of newline characters! > >> Is this still a problem? I have updated NLS in git. >> >> However, I'm not certain the en@boldquot stuff makes sense any more. It >> was used to be recommended for projects, but it seems to have fallen out >> of fashion. Should we just drop the en@* stuff? > > The failure appears for me with FreeBSD, never with GNU/Linux. > The error is caused by > > msgmerge --lang=en@quot e...@quot.po shishi.pot -o e...@quot.new.po > > which is inserting "\n" at the end of every generated msgstr. > The most probable cause is that FreeBSD does not provide the > locales "en@quot" and "en@boldquot". > > There should really be a test whether these locales exist, > before creating the message templates. Building these files should not require locales at all. Perhaps there is a genuine gettext-on-FreeBSD bug lurking here? Which gettext version are you using? However maybe the simplest is to remove these locales, I'm not sure generating them are considered best practice any longer. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Build failure of 1.0.2 for FreeBSD.
Mats Erik Andersson writes: > Hello there, > > I have discovered that the updated Gnulib source > displays the bad habit of putting essential macros > into , at least for use on FreeBSD. > So much for portability! Sigh. > Only the sources in "examples/" are touched by this, > and only when using the replacement headers from Gnulib. > When the examples are compiled against the system headers > of FreeBSD all goes well. > > Observe that release 1.0.2 as well as shishi-master are > effected. I have just pushed a commit "cbc4c1ca" that is > in itself capable to repair release 1.0.2 to full build. Thanks. Btw, you don't need to write ChangeLog entries: the ChangeLog file is automatically generated from the git log messages at release time. Just make sure the git log messages are reasonable. > P.S. Is there something akin to "commit-shishi" for getting > to read commit messages, like with "commit-inetutils"? Yes: http://lists.gnu.org/archive/html/shishi-commit/ /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Shishi 1.0.2 released
Shishi is an implementation of the Kerberos 5 network authentication
system. Shishi can be used to authenticate users in distributed
systems. Shishi is part of a GNU system.
* Version 1.0.2 (released 2013-04-03)
** libshishi: Fix server-realm handling.
Reported by Mats Erik Andersson .
** libshishi: Fix salt derivation for principals with multiple components.
Before, when adding a principal such as "user/admin" using shisa it
would use the wrong salt. Reported by Mats Erik Andersson
.
** libshishi: Fix setting principals with multiple components in encticketpart.
Before, the shishid KDC would return the wrong client principal name
in a KDC-REP when principals such as "user/admin" were used. That
would lead to errors when getting a ticket for such principals.
Reported by Mats Erik Andersson .
** libshishi: Fixes to .k5login authorization.
Patch by Mats Erik Andersson .
** shishid: The syslog facility is now LOG_AUTH instead of LOG_DAEMON.
Suggested by Mats Erik Andersson .
** minitasn1: Removed. You must use an external installed libtasn1.
With recent libtasn1 it is no longer trivial to build libtasn1 as
copied source code files.
** Update gnulib files and various other fixes.
Shishi contains a library ('libshishi') that can be used by application
developers to add support for Kerberos 5. Shishi contains a command
line utility ('shishi') that is used by users to acquire and manage
tickets (and more). The server side, a Key Distribution Center (KDC),
is implemented by 'shishid', and support X.509 authenticated TLS via
GnuTLS. Of course, a manual documenting usage aspects as well as the
programming API is included.
Shishi currently supports AS/TGS exchanges for acquiring tickets,
pre-authentication, the AP exchange for performing client and server
authentication, and SAFE/PRIV for integrity/privacy protected
application data exchanges. The DES, 3DES, ARCFOUR, and AES
cryptographic algorithms are supported.
Shishi aims to be internationalized, thread safe and portable. Shishi
is written in ANSI/ISO C89, and has been ported to numerous platforms,
including most major Unix platforms and Windows, running on devices
including iPAQ handhelds and S/390 mainframes. Shishi can also be cross
compiled to Microsoft Windows using mingw32 and embedded platforms such
as the Motorola Coldfire.
Current work items include improvements on the server (KDC), integration
of initial authentication via OpenPGP using GnuTLS, set-passwd
implementation, and a LDAP backend for the Shisa library used in the KDC
for information storage. Assistance is appreciated on any of these (or
other) items.
The project web page is available at:
https://www.gnu.org/software/shishi/
All manuals are available from:
https://www.gnu.org/software/shishi/manual/
Direct links to the manual:
HTML: https://www.gnu.org/software/shishi/manual/shishi.html
PDF: https://www.gnu.org/software/shishi/manual/shishi.pdf
Direct links to the API Reference manual:
HTML: https://www.gnu.org/software/shishi/reference/
PDF: https://www.gnu.org/software/shishi/reference/shishi.pdf
For code coverage and cyclomatic code complexity charts:
https://www.gnu.org/software/shishi/coverage/
https://www.gnu.org/software/shishi/cyclo/cyclo-shishi.html
If you need help to use Shishi, or want to help others, you are
invited to join our help-shishi mailing list, see:
<https://lists.gnu.org/mailman/listinfo/help-shishi>.
Here are the compressed sources (4.8MB):
ftp://ftp.gnu.org/gnu/shishi/shishi-1.0.2.tar.gz
http://ftp.gnu.org/gnu/shishi/shishi-1.0.2.tar.gz
Here are GPG detached signatures signed using key 0xB565716F:
ftp://ftp.gnu.org/gnu/shishi/shishi-1.0.2.tar.gz.sig
http://ftp.gnu.org/gnu/shishi/shishi-1.0.2.tar.gz.sig
Improving Shishi is costly, but you can help! We are looking for
organizations that find Shishi useful and wish to contribute back. You
can contribute by reporting bugs, improve the software, or donate money
or equipment.
Commercial support contracts for Shishi are available, and they help
finance continued maintenance. Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding Shishi
maintenance. We are always looking for interesting development
projects. See http://josefsson.org/ for more details.
The software is cryptographically signed by the author using an OpenPGP
key identified by the following information:
pub 1280R/B565716F 2002-05-05 [expires: 2013-05-10]
Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F
uid Simon Josefsson
sub 2048R/105E722E 2012-03-13 [expires: 2013-07-26]
The key is available from:
http://josefsson.org/key.txt
dns:b565716f.josefsson.org?TYPE=CERT
Here are the SHA-1 and SHA-224 checksums:
c065838baae18d2e39ccd0556e7b7364e2db48bb shishi-1.0.2.tar.gz
1244002979c0087cb3ebbaee9faab5b1e11391e3607f40cbd1d9223c shishi-1.0.2.tar.gz
H
Re: On non-PIC PAM module for OpenSolaris.
Russ Allbery writes: > Simon Josefsson writes: > >> So, is there a standard idiom to turn --with-pic on by default that we >> should use? Or just document this fact somewhere? > > I'm confused about how you have this problem, since by default libtool > uses PIC for all shared objects, and I'm not sure why the PAM module > wouldn't be a shared object. > > Oh, I wonder if the problem is just that you're missing -shared in the > pam_shishi_la_LDFLAGS setting. You have: > > pam_shishi_la_LDFLAGS = -module -avoid-version > > and my PAM module packages all have: > > pam_krb5_la_LDFLAGS = -module -shared -avoid-version $(VERSION_LDFLAGS) \ > $(AM_LDFLAGS) > > (for example). > > PAM modules should always be shared; static PAM modules really don't make > any sense on nearly all systems. I've never had a request for one in > years of maintaining PAM modules. I have added -shared now, it makes sense to me as well. Thanks, /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On shisa and its password disclosure.
Mats Erik Andersson writes: > Dear all, > > I am somewhat disturbed by that fact that the superuser > is able to execute > ># shisa -d --keys > > thereby gaining access to all passwords for all principals > of the running KDC. > > Contrast this to the situation with MIT Kerberos or Heimdal, > where a selected administrator is entrusted with the power to > inspect such secrecies, which the superuser is unable to access, > unless he was able to snoop the administrator's password. > > Am I lacking some insight, or is there a security issue here? This was a design choice. It may not have been the best one. Storing the password allows some flexibility if crypto parameters needs to be changed later on. The KDC can then recompute the hashed keys. It also allows the same password database to be used by other protocols in the future, that may need access to the raw password. Remember, it should be _possible_ to use the Shishi KDC without storing the password: just convert a password to a key and then store that in the database. So someone genuinely concerned about this should be able to work around it. There ought to be a parameter to shisa, possibly even enabled by default, that forgets the password after generating a key that is stored on disk. This would make it easier to setup a KDC without storing plaintext passwords. Still, I believe it should be possible to use the current approach too: some may want the flexibility gained by storing the plaintext passwords. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Neglected source tree.
Simon Josefsson writes: >> By the way, when do you intend to look into the issues with >> getsubopt() and res_query() needed for portability to non-Glibc, >> for which I have already submitted tried and tested patches? > > I'll take a look now. Re getsubopt, the patch seems to have been applied in August 2012 according to git log. Is there anything more needed here? I'm comparing your email here: http://permalink.gmane.org/gmane.comp.gnu.shishi.general/740 with this commit here: http://git.savannah.gnu.org/cgit/shishi.git/commit/?id=d5b939b17ef241473aec023cc512be3971c8e008 Did you send another email about getsubopt? Re res_query, I have pushed the latest patch I could find from you -- please double check it. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishi-NLS: e...@boldquot.po is broken
Mats Erik Andersson writes: > Hello there, > > the imported file > >po/e...@boldquot.po > > is broken, because 176 msgid/msgstr pairs are not > agreeing on the use of newline characters! > > The make target is conceived to use > > msgfmt -c ... > > so the mismatch of ending "\n" causes 176 errors. Is this still a problem? I have updated NLS in git. However, I'm not certain the en@boldquot stuff makes sense any more. It was used to be recommended for projects, but it seems to have fallen out of fashion. Should we just drop the en@* stuff? /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Minor documentation issue.
Mats Erik Andersson writes: > Here are some minor documentation updates, including > a missing function description. Splendid! Applied. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishi-1.0.1 build failure with glibc-2.16.0
Eray Aslan writes: > shishi-1.0.1 fails to build with glibc-2.16.0 with: > > [...] > In file included from md4.h:23:0, > from md4.c:25: > ./stdio.h:1030:1: error: 'gets' undeclared here (not in a function) > > gets is required by C89, deprecated in C99 and was removed in C11. The > attached patch works for me and is similar to what gnulib does [1] Thank you. This should also be fixed in Shishi from git because it uses a more modern gnulib version. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On non-PIC PAM module for OpenSolaris.
Mats Erik Andersson writes: > Dear Russ Albery, > > fredag den 5 oktober 2012 klockan 12:23 skrev Russ Allbery detta: >> Mats Erik Andersson writes: >> >> > there is a problem with pam_shishi.so in OpenSolaris >> > and OpenIndiana. The module builds well with "--with-pic", >> > but fails completely without PIC. >> >> When would you build a non-PIC PAM module for Solaris? I didn't think >> Solaris supported static PAM modules. >> >> In other words, is the actual bug that --with-pic is not the default on >> Solaris? > > Indeed! This hits the mark for flavours of Solaris. So, is there a standard idiom to turn --with-pic on by default that we should use? Or just document this fact somewhere? Thanks, /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Incomplete inclusion paths.
Mats Erik Andersson writes: > Hello there, > > when building out-of-tree the inclusion paths > declared in "examples/", "extra/pam_shishi/", > and "extra/rsh-redone/" are incomplete. Thanks, applied. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Neglected source tree.
Mats Erik Andersson writes: > Hello there, > > which year do you intend to maintain Shishi properly? > You claimed version 1.0.*, so please accept the duty > to maintain this source, in preference to developing > other material from scratch. As long as you enforce > >### configure.ac > >AM_INIT_AUTOMAKE([1.10 -Wall -Werror -Wno-override]) > > with "-Werror", you are responsible for being attentative > enough to adapt to recent tool changes. Hi. I have dropped -Werror in git now. > automake-1.12 has made changes targetting AC_PROG_MKDIR_P > over AM_PROG_MKDIR_P, and separately become dependent on > AM_PROG_AR. > > The former issue needs updated source from GNUlib as long > as "-Werror" is in use, and was attended to by GNUlib in > December, 2012. Observe also that AM_PROG_MKDIR_P will be > made obsolete in automake-1.14. > > The issue with AM_PROG_AR is resolved by the patch below. Thanks, applied. > By the way, when do you intend to look into the issues with > getsubopt() and res_query() needed for portability to non-Glibc, > for which I have already submitted tried and tested patches? I'll take a look now. Btw, I have given you commit rights on savannah to the Shishi project. Feel free to install simple fixes when you find them. We should aim to get a maintenance 1.0.2 out relatively soon, to get your fixes out there, so please don't introduce anything unstable or add any new features in the next month at least. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: error building Shishi version 1.0.1, undeclared MAX_ERROR_DESCRIPTION_SIZE
Marco Maggi writes: > Ciao, > > I am no expert of crypto libraries; on my i686-pc-linux-gnu, I > fail to build version 1.0.1 because of the error: > >make[3]: Entering directory `/home/marco/var/build/lib/shishi-1.0.1/lib' > CC asn1.lo >asn1.c: In function '_shishi_asn1_init': >asn1.c:42:25: error: 'MAX_ERROR_DESCRIPTION_SIZE' undeclared (first use in > this function) >asn1.c:42:25: note: each undeclared identifier is reported only once for > each function it appears in >asn1.c: In function 'shishi_asn1_to_der_field': >asn1.c:767:25: error: 'MAX_ERROR_DESCRIPTION_SIZE' undeclared (first use > in this function) >asn1.c: In function 'der2asn1': >asn1.c:850:25: error: 'MAX_ERROR_DESCRIPTION_SIZE' undeclared (first use > in this function) > > it appears that Libtasn1 version 3.2 does not define > MAX_ERROR_DESCRIPTION_SIZEanymore;rather itdefines: > ASN1_MAX_ERROR_DESCRIPTION_SIZE. > > I dunno which version of Libtasn1 removed definitions, but > MAX_ERROR_DESCRIPTION_SIZE was already commented as deprecated in > Libtasn1 version 2.12 (in the header file). Right -- Shishi hasn't been updated in a while, and used now deprecated definitions from libtasn1. It should be easy to fix. > I canbuild if I usethe configuration option > --without-system-asn1; I do not see this mentioned in the README > file. Right, that workaround will work. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On server-realm wildcards.
This patch is not applicable after your other server-realm fixes, right? /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Listening wildcards in shishid.
Mats Erik Andersson writes: > Hello again, > > on a dual stacked system, having shishid(8) listen > on a naive AF_INET6 wildcard address, is causing > a bind failure for any AF_INET wildcard address. > It is better to set the socket option IPV6_V6ONLY > on all AF_INET6 listening sockets in order that > no AF_INET socket be rejected, causing an annoying > error message of no use. Patch included. Thank you, applied and pushed. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Server-realm configuration stanzas.
Mats Erik Andersson writes: > The new patch-suggestion has been verified for GNU/Linux, > OpenSolaris, and FreeBSD 8.2, providing full functionality > in shishi_realm_for_server(), in configuration as well as > using network lookup. Thank you! Applied and pushed. Is this now used in inetutils? /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Server-realm configuration stanzas.
Mats Erik Andersson writes: > In order to enhance my credibility, let me produce > a test case for getsubopt() that illuminates the > failure of the present implementation of shishi_cfg(). Thank you! I believe you have identified a difference between GNU and POSIX getsubopt. Possibly gnulib should work around this problem. I'm redirecting this to the gnulib list for further discussion by the experts. Gnulib's getsubopt portability issues are documented here: http://www.gnu.org/software/gnulib/manual/html_node/getsubopt.html It only says the function is missing on some platforms, not any other portability concerns. The POSIX spec is here: http://pubs.opengroup.org/onlinepubs/009695399/functions/getsubopt.html Note: If the string at *optionp contains only one suboption argument (equivalently, no commas), getsubopt() shall update *optionp to point to the null character at the end of the string. Otherwise, it shall isolate the suboption argument by replacing the comma separator with a null character, and shall update *optionp to point to the start of the next suboption argument. If the suboption argument has an associated value (equivalently, contains an equal sign), getsubopt() shall update *valuep to point to the value's first character. Otherwise, it shall set *valuep to a null pointer. The calling application may use this information to determine whether the presence or absence of a value for the suboption is an error. Additionally, when getsubopt() fails to match the suboption argument with a token in the keylistp array, the calling application should decide if this is an error, or if the unrecognized option should be processed in another way. Alas the final paragraph doesn't demand any specific behaviour of getsubopt when there is no match, however the paragraph begins with "Additionaly" so presumably (*) whatever is done when there is no match is done on top of what is normally done, which is covered by the previous paragraph. (*) This is debatable, but was my initial reading. The GNU libc documentation is here: http://www.gnu.org/software/libc/manual/html_node/Suboptions.html#Suboptions Note: In case the suboption has an associated value introduced by a `=' character, a pointer to the value is returned in VALUEP. The string is `\0' terminated. If no argument is available VALUEP is set to the null pointer. By doing this the caller can check whether a necessary value is given or whether no unexpected value is present. In case the next suboption in the string is not mentioned in the TOKENS array the starting address of the suboption including a possible value is returned in VALUEP and the return value of the function is `-1'. I'm not sure the final paragraph is POSIX compliant. The first paragraph in the POSIX spec quoted above says VALUEP should be NULL if there is no argument, and presumably that applies even if there is no token match. GNU behaves different when there is no token match. The glibc implemtation is here: http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/getsubopt.c;h=e770c2d8471f348b083b3a92ee87b74395bf0a9b;hb=HEAD#l32 Note: /* Parse comma separated suboption from *OPTIONP and match against strings in TOKENS. If found return index and set *VALUEP to optional value introduced by an equal sign. If the suboption is not part of TOKENS return in *VALUEP beginning of unknown suboption. On exit *OPTIONP is set to the beginning of the next token or at the terminating NUL character. */ int getsubopt (char **optionp, char *const *tokens, char **valuep) So I think a portable program that uses getsubopt needs to save a copy of optionp before passing it to getsubopt, and then if getsubopt returns -1 it needs to look at that copy instead of value. If the application is interested in what the unknown suboption was, that is. > The test program "test_subopt.c", contained in the present > message, produces the following output at execution time. > > GNU libc, OpenSolaris: > > INPUT: name=this,that,those > > NAME: value = 'this', tail = 'that,those' > default: value = 'that', tail = 'those' > default: value = 'those', tail = '' This seems to be the problem: value should be NULL in the last two lines. > FreeBSD 8.2, FreeBSD 9.0, OpenBSD 5.0, NetBSD 5.1, DragonflyBSD 3.1: > > INPUT: name=this,that,those > > NAME: value = 'this', tail = 'that,those' > default: value = '(null)', tail = 'those' > default: value = '(null)', tail = '' This seems consistent with POSIX. > A common feature in the BSD implementation is to empty VALUE in > > getsubopt(&tail, token, &value); > > in case an unrecognised suboption is found. The implementations > in eglibc and in SunOS libc do not behave that way. Can you also print out what the return value from getsubopt is in the 'default' value? Is it -1 or so
Re: Gnu-isms in makefile templates.
Mats Erik Andersson writes: > Hello again, > > there are unfortunate Gnu-isms in "doc/Makefile.am", "lib/Makefile.am", > and "src/Makefile.am". The problem lies in the use of $^ and $<, which > are not universal. Resolving these references allows BSD make to build > the source as build-inside-source, at least on FreeBSD and NetBSD. Thank you! Applied. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Simon Josefsson writes: > I'm inclined to use LOG_AUTH instead and file a bug report on the man > page to drop the remark about deprecation. Pushed now. See also https://bugzilla.kernel.org/show_bug.cgi?id=46091 Interestingly, I found an old ChangeLog entry: 2003-07-10 Simon Josefsson * src/shishid.c: Use LOG_DAEMON instead of LOG_AUTHPRIV (make this configurable?). I suppose making it configurable would indeed be nice. However, we still need a default value, and it should probably be LOG_AUTH. Thanks Russ for input on this! /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Mats Erik Andersson writes:
> torsdag den 16 augusti 2012 klockan 22:23 skrev Simon Josefsson detta:
>> Mats Erik Andersson writes:
>>
>> > Anyway, you should provide for LOG_AUTH.
>> >
>> > BSD systems use two different settings as standard,
>> > and the are not using "/var/log/syslog" at all:
>>
>> Interesting. The reason I used LOG_AUTHPRIV instead of LOG_AUTH was
>> that my syslog manpage (Ubuntu 12.04) says:
>>
>>LOG_AUTH security/authorizationmessages(DEPRECATED
>> Use
>> LOG_AUTHPRIV instead)
>
> You are somewhat jumping your conclusions here. Taking further advice
> from on GNU/Linux or BSD will clarify the matter:
>
>
> { "security", LOG_AUTH } /* DEPRECATED */
>
> but
>
> { "auth", LOG_AUTH }
> { "authpriv", LOG_AUTHPRIV }
>
> are still recommended. Observe the nomen "security", which is
> better avoided since a rather long time.
Agreed -- but doesn't that just imply that use of the "security" name is
deprecated? My man page implied LOG_AUTH was deprecated, which seems
different.
I could not find anything about LOG_AUTH being deprecated in the GNU
libc manual or source code. RFC 5424 describes (informally) both
facilities (by code, 4 and 10). RFC 3164 contains a note:
Note 1 - Various operating systems have been found to utilize
Facilities 4, 10, 13 and 14 for security/authorization,
audit, and alert messages which seem to be similar.
RFC5427 describe "auth" as "authorization messages" and "authpriv" as
"security/authorization messages".
MIT's krb5.conf says they use LOG_AUTH per default.
I'm inclined to use LOG_AUTH instead and file a bug report on the man
page to drop the remark about deprecation.
/Simon
___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Russ Allbery writes: > Simon Josefsson writes: > >> Thanks -- I have changed shishid to use LOG_AUTHPRIV now (we'll see how >> portable that is compared to LOG_AUTH...). > > You should only use LOG_AUTHPRIV for auth logs that have a substantial > risk of recording someone's password. I'm not sure if this situation > applies. It's normally used by PAM modules, but not by Kerberos KDCs. > > Anyway, every piece of code I've ever seen that uses LOG_AUTHPRIV has in > it something akin to: > > #ifndef LOG_AUTHPRIV > # define LOG_AUTHPRIV LOG_AUTH > #endif I don't think shishid would ever syslog any passwords. So maybe we should use LOG_AUTH instead, then? I wonder why LOG_AUTH was marked deprecated in my man page... /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Mats Erik Andersson writes:
> torsdag den 16 augusti 2012 klockan 08:46 skrev Simon Josefsson detta:
>> Russ Allbery writes:
>>
>> > Simon Josefsson writes:
>> >
>> >> I believe these are important for knowing when someone got a ticket, so
>> >> they should definitely be in the syslog. If we are changing this one to
>> >> LOG_AUTH, many other messages should also be moved, since they also
>> >> print user information. However, I wonder what MIT/Heimdal does, or
>> >> what other servers do, like sshd?
>> >
>> > Heimdal uses LOG_AUTH. I believe MIT does as well, although I'm finding
>> > it difficult to locate the exact code that sets the default. sshd uses
>> > LOG_AUTH.
>>
>> Thanks -- I have changed shishid to use LOG_AUTHPRIV now (we'll see how
>> portable that is compared to LOG_AUTH...).
>
> Right decision, a clear improvement.
>
> GNU/Linux and BSD offer
>
> { "auth", LOG_AUTH },
> { "authpriv", LOG_AUTHPRIV }
>
> as distinct facilities, Solaris offer only
>
> { "auth", LOG_AUTH }
>
> and commercial unices are not available to me.
> Anyway, you should provide for LOG_AUTH.
>
> BSD systems use two different settings as standard,
> and the are not using "/var/log/syslog" at all:
Interesting. The reason I used LOG_AUTHPRIV instead of LOG_AUTH was
that my syslog manpage (Ubuntu 12.04) says:
LOG_AUTH security/authorizationmessages(DEPRECATEDUse
LOG_AUTHPRIV instead)
I kind of guessed that the situation wasn't as simple as that...
/Simon
___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Russ Allbery writes: > Simon Josefsson writes: > >> I believe these are important for knowing when someone got a ticket, so >> they should definitely be in the syslog. If we are changing this one to >> LOG_AUTH, many other messages should also be moved, since they also >> print user information. However, I wonder what MIT/Heimdal does, or >> what other servers do, like sshd? > > Heimdal uses LOG_AUTH. I believe MIT does as well, although I'm finding > it difficult to locate the exact code that sets the default. sshd uses > LOG_AUTH. Thanks -- I have changed shishid to use LOG_AUTHPRIV now (we'll see how portable that is compared to LOG_AUTH...). /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Tickets with instance names.
Mats Erik Andersson writes: > onsdag den 15 augusti 2012 klockan 23:03 skrev Simon Josefsson detta: >> >> I could confirm this -- there were two different problems: >> >> 1) The parsing bug that we fixed. >> >> 2) Shisa doesn't derive the salt for foo/bar@baz principals correctly, >>it should be "bazfoobar" but it will use "bazfoo/bar" instead. The >>bug is in shishi_derive_default_salt. >> >> As a workaround, when adding the user/admin user, specify the --salt >> parameter, like this: >> >> shisa -a --password --salt interop.josefsson.orguseradmin >> interop.josefsson.org user/admin >> >> then it should work. Use -n instead of -a to update the key. > > I can confirm that this work around is functional, but I am > puzzled that two different keys present in "shishi.keys" still > do not confuse the execution. Probably intended, but unexpected. > > Anyway, this work around clearly indicates that 2. is at the core > of the present problem. I have fixed the 2 bug now. The shishi.keys file can contain several keys (different enctypes, different salt, etc) and the code should find the right one for each situation. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Eray Aslan writes: > On 08/15/2012 08:46 PM, Simon Josefsson wrote: >> However, I wonder what MIT/Heimdal does, or >> what other servers do, like sshd? > > MIT/Heimdal default to using LOG_AUTH for syslog. sshd also uses > LOG_AUTH afaik. > >> On systems I'm >> familiar with, reading the syslog requires the same privileges as >> reading the authlog > > Usually but not always. Use LOG_AUTH and let the sysadmin decide? So should we use LOG_AUTH for all messages from shishid, then? That sounds the most logical to me. Everything shishid does is authentication related. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Tickets with instance names.
Mats Erik Andersson writes: > The following crude patch allows the exchange to proceed further. > Now the procedure get as far as halting on failed HMAC verification. > More investigation is needed. I could confirm this -- there were two different problems: 1) The parsing bug that we fixed. 2) Shisa doesn't derive the salt for foo/bar@baz principals correctly, it should be "bazfoobar" but it will use "bazfoo/bar" instead. The bug is in shishi_derive_default_salt. As a workaround, when adding the user/admin user, specify the --salt parameter, like this: shisa -a --password --salt interop.josefsson.orguseradmin interop.josefsson.org user/admin then it should work. Use -n instead of -a to update the key. I'll look at the shishi_derive_default_salt bug tomorrow. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On shishi_parse_name().
Mats Erik Andersson writes: > - * @name: input principal name string, e.g. imap/mail.gnu@gnu.org. > + * @name: input principal name string, e.g. imap/mail.gnu.org@@GNU.ORG. ... > - * Split principal name (e.g., "si...@josefsson.org") into two > + * Split principal name (e.g., "simon@@JOSEFSSON.ORG") into two This part didn't work, I got build failures. It seems GTK-DOC uses \ to escape @, see: http://developer.gnome.org/gtk-doc-manual/unstable/documenting_syntax.html.en I have fixed this on git master. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Tickets with instance names.
Mats Erik Andersson writes: > onsdag den 15 augusti 2012 klockan 13:06 skrev Mats Erik Andersson detta: >> torsdag den 9 augusti 2012 klockan 23:14 skrev Simon Josefsson detta: >> > Mats Erik Andersson writes: >> > >> > > Am I incorrect in believing that AS-REP was built from incorrect >> > > data, since the name string is not split into name proper and >> > > instance name? >> > >> > Yes. The code parsing sigge/admin should probably have splitted that >> > into two components. Is that a Shishi KDC? It sounds like a bug. >> >> Client and server built from GNU Inetutils development head, >> so libshishi is incomplete here. A quick search reveals that >> "lib/encticketpart.c" and "lib/kdc.c" are accessing the ASN.1 >> descriptor "sname.name-string", so presumably either of these >> files could be cheating. > > The following crude patch allows the exchange to proceed further. Thanks for tracking it down, I solved it somewhat differently on git master. I also added a regression test for this problem, as it was a real bug. > Now the procedure get as far as halting on failed HMAC verification. > More investigation is needed. The principal names are usually part of the salting, that's why those things can fail. Retry with my patch, and if that doesn't work, try to debug it further. Thanks, /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On shishi_parse_name().
Mats Erik Andersson writes: >> > so the expected call shishi_error() is reporting irrelevant text when >> > called after a failure in shishi_parse_name(). Can an error >> > condition in shishi_parse_name() be inserted into the handle's >> > context? >> >> I've added some shishi_error_printf, what do you think? > > I was kind of wandering whether there exists an API call > that lets me register an error condition in the handle. > Intuitively I was hoping for a call like > > shishi_register_error_state (handle, shishi_errno, err_msg); > > which would raise, in the opaque Shishi handle, whatever > error semaphors there might be. Should shishi_parse_name() > be discontent with the given principal name, this would > provide a means for reporting an error exception. I don't think there is anything like that, and I'm not sure how it would work or how it would be useful. If you want to pursue it, explaining more and providing patches will be fine. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: shishid: Usage of syslog facilities.
Mats Erik Andersson writes: > Hello again, > > let me suggest changes to the way shishid(8) > is submitting messages to LOG_DAEMON. A patch > suggestion is addressing these matters. > > Contrary to claim in "src/kdc.c", shishid(8) is > committing non-error messages "Trying AS-REQ" > and "Trying TGS-REQ" in facility LOG_ERR. > Change these to use LOG_DEBUG. These messages are rather useless, even on debug level. I have removed them completely. > The mandatory use of LOG_PERROR in "src/shishid.c" > is a mistake. It is better to condition use of > LOG_PERROR in openlog() on the test > > if (arg.verbose_given > 0) Agreed, applied. > There is a further delicate issue with two LOG_INFO > messages in "src/kdc.c": > >"AS-REQ from %s@%s for %s@%s" >"TGS-REQ from %s@%s for %s@%s" > > I suggest downgrading to LOG_DEBUG and also to issue > them only if "arg.verbose_given > 0". However, both > messages present a security issue since they disclose > user information, Hence they should arguably only be sent > to LOG_AUTH, if committed at all instead of just calling > printf() for the running executable shishid(8). I believe these are important for knowing when someone got a ticket, so they should definitely be in the syslog. If we are changing this one to LOG_AUTH, many other messages should also be moved, since they also print user information. However, I wonder what MIT/Heimdal does, or what other servers do, like sshd? I think having user information in /var/log/syslog is fairly common, but I may be mistaken. On systems I'm familiar with, reading the syslog requires the same privileges as reading the authlog so for security I don't think it matters much. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Coverage of error strings.
Mats Erik Andersson writes: > Hello there, > > I find that "lib/error.c" is wanton of most error strings. > Since I put a number of them to use in GNU Inetutils, I have > attempted to make the list complete. Admittedly many of the > strings are guesses on my behalf as I have never met them, > but I believe it to be valuable for administrators and user > to get to see something better than "Unknown error"! Applied, thank you! /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: On shishi_parse_name().
Mats Erik Andersson writes: > Hello, > > the manual page and all documentation of > shishi_parse_name() are inaccurate in the > way they fail to contain an at-sign between > principal name and realm name in two cases. > Also the variable referencing is in error. > The following patch suggestion might mend > this, but I have not really executed the > parsers on the change, though. I have applied the patch, thank you. > The API call shishi_parse_name() is notable > on two more accounts: > > * The Shishi handle is part of the signature, >but it is never used, Yes, this was intentional so that if something from the handle will ever be needed in the future, we can use it. > so the expected call shishi_error() is reporting irrelevant text when > called after a failure in shishi_parse_name(). Can an error > condition in shishi_parse_name() be inserted into the handle's > context? I've added some shishi_error_printf, what do you think? > * There is an asymmetry in the return values >`*principal' and `*realm', since the former >always is allocated, while the latter need >not be so. Would it be disruptive to return >`*principal' as NULL when the component is >missing? I have good use of the call > > shishi_parse_name(&h, "@EX.ORG", &principal, &realm) > >which displays asymmetry in relation to > > shishi_parse_name(&h, "me/admin", &principal, &realm) > >since `realm = "EX.ORG"' and `principal = ""' in the first >case, and `principal' must be deallocated afterwards. >In contrast, the second case has `realm = NULL'. I think this is fine, patches welcome! /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Detection of in BSD.
Mats, could you please re-try whether -lresolv detection works on BSDs? I have changed it to use AC_LIB_HAVE_LINKFLAGS instead which should be more reliable and flexible. What I'm uncertain about is: doesn't BSDs provide libresolv at all? If it doesn't, we need to re-apply parts of your patch after the current AC_LIB_HAVE_LINKFLAGS change. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi 1.0.1 released
Eray Aslan writes: > On 08/09/2012 12:39 AM, Simon Josefsson wrote: >> I just pushed another patch to resolve resolver linking issues, >> could you test whether it also solves your problem? > > That would be commit 63023d749f4f7 I guess. Still no go: > > [...] > checking for res_query... no > checking for res_query in -lresolv... no > configure: WARNING: no libresolv, SRV RRs not used I was able to reproduce this now. I have installed another patch, please test latest git. Thanks, /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Tickets with instance names.
Mats Erik Andersson writes:
> Hello again,
>
> I am not sure whether the following is due to my lack of
> understanding the matter at hand, or wether there is a
> incompleteness on behalf of libshishi.
>
> I have created an administrator
>
> # shisa -a --password LOCALHOST sigge/admin
>
> Then I request a TGT in my administrator role:
>
> $ shishi sigge/admin@LOCALHOST
>
> This fails due to SHISHI_CNAME_MISMATCH. In fact,
>
> AS-REQ: "req-body.cname.name-string" -> { "sigge", "admin" }
>
> is of componen length 2, whereas
>
> AS-REP: "cname.name-string" -> { "sigge/admin" }
>
> is of component length 1. Thus shishi_as_check_cname() fails
> immediately.
>
> Am I incorrect in believing that AS-REP was built from incorrect
> data, since the name string is not split into name proper and
> instance name?
Yes. The code parsing sigge/admin should probably have splitted that
into two components. Is that a Shishi KDC? It sounds like a bug.
/Simon
___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi 1.0.1 released
Eray Aslan writes: > On Mon, Mar 12, 2012 at 08:22:49PM +0100, Simon Josefsson wrote: >> Shishi is an implementation of the Kerberos 5 network authentication >> system. Shishi can be used to authenticate users in distributed >> systems. Shishi is part of a GNU system. >> >> * Version 1.0.1 (released 2012-03-12) > > libresolv.so does not provide res_query on some architectures. At least > on amd64 here, libresolv.so provides __res_query only and res_query is > defined by resolv.h. So, configure cannot find res_query in libresolv.so > with AC_CHECK_LIB. > > The attached patch includes resolv.h in the test and works for me. Hi Eray, sorry about slow response. I just pushed another patch to resolve resolver linking issues, could you test whether it also solves your problem? You didn't mention which OS you were using, is it a BSD system? /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Detection of in BSD.
Mats Erik Andersson writes: > The following patch allows build of libshishi on FreeBSD, > NetBSD, and DragonflyBSD. Thank you, applied. Sorry about slow response. I think we are closing in on a 1.0.2 release... /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: 64-bit issue with checksumming.
Mats Erik Andersson writes: > onsdag den 8 augusti 2012 klockan 15:50 skrev Simon Josefsson detta: >> Mats Erik Andersson writes: >> >> > Hello there, >> > >> > I have found a discrepancy between 32-bit Wheezy and >> > 64-bit Squeeze systems. >> >> Interesting, are you able to reproduce this in some easy way? Could >> this be related to this problem: >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670316 >> >> Maybe you could try that patch and see if it solves your problem. > > The cause was to be found entirely within GNU Inetutils. > It was mended in commit 7129ba40. It boiled down to the > fact that the original author of the libshishi support in > "src/rshd.c", "src/rlogind.c", and "libinetutils/shishi.c" > passed integer types "int outlen" where "size_t outlen" > was in use by libshishi. On 64-bit systems these are not > interchangeable, so communication failed. > > Case is closed as fas as I know. Great, thank you for tracking this down! /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Mixed spelling issues in texinfo source.
Mats Erik Andersson writes: > The following spelling errors make fos a small selection > I found while reading some few select parts. Thank you! English isn't my native tounge, so review of the documentation is definitely needed. Applied and pushed. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: 64-bit issue with checksumming.
Mats Erik Andersson writes: > Hello there, > > I have found a discrepancy between 32-bit Wheezy and > 64-bit Squeeze systems. > > Both systems deliver cksumtype 0x07 and length 16 > as reported by ASN.1 verbose reports, but > > shishi_authenticator_cksum() > > is returning cksumtype 0x07 on i386, and 0x00 on amd64. > > As a consequence, shishi_checksum() is returning data > of length 12, when fed with the previous setup data. > Manually forcing cksumtype 0x07 into shishi_checksum(), > by overriding the claim from shishi_authenticator_cksum(), > will restore the expected functionality. > > Thus shishi_asn1_read() is not able to firmly establish > the encryption type, but ASN.1 reports correct debugging > text. It seems that shishi_asn1_read_int32() and macro > C2I are defective. Broken representation of ASN.1 data? Interesting, are you able to reproduce this in some easy way? Could this be related to this problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670316 Maybe you could try that patch and see if it solves your problem. There is a bunch of ugly casts in Shish that could explain issues like this. I'd like to address them, but goings are going slowly... /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi
phi...@free.fr writes: > Hello, > > I need to create a service principal to test a Spring Kerberos application > example. > > In this article > http://blog.springsource.org/2009/09/28/spring-security-kerberos/, the > author recommends > typing the following commands to create the principal and add it to a keytab > > ktpass /out http-web.keytab /mapuser > http-web.springsource@springsource.com /princ > HTTP/web.springsource@springsource.com /pass * > > > on Windows > > kadmin: addprinc -randkey HTTP/web.springsource.com > kadmin: ktadd -k /http-web.keytab HTTP/web.springsource.com > > on Linux > > > In Shishi, the equivalent of the first Linux command, is, I guess, > > shisa -a SPRINGSOURCE.COM krbtgt/SPRINGSOURCE.COM HTTP/web.springsource.com > > > What is the equivalent of the second command (ktadd)? You need to do it in two steps, first export the key from the KDC database using 'shisa', for example: shisa --dump --keys SPRINGSOURCE.COM HTTP/web.springsource.com > http-web-key.txt keytab2shishi --reverse http-web-key.txt http-web.keytab Possibly this functionality could be merged into shisa to make things easier. > How do I map the equivalent of the above keytab to the > http-web.springsource.com user? > > (http-web.springsource@springsource.com) I'm not sure I understand this question. Generally, you'll have to configure the application to access the server keytab it needs. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Solved: shishi directory rights
The /usr/local/var/shishi (or /var/lib/shishi) hierarchy contains encryption keys, and should only be readable by the KDC process and the administrator. If 'me:me' is the Shishi KDC admin, your permissions are fine. /Simon phi...@free.fr writes: > sudo chown -R me:me /usr/local/var/shishi solved the problem. > > Philroc > > > > > - Mail transféré - > De: phi...@free.fr > À: help-shishi@gnu.org > Envoyé: Vendredi 13 Juillet 2012 16:26:39 > Objet: shishi directory rights > > Hello, > > when I type shisa -d > > I get the message > > /usr/local/var/shishi: Permission denied > > If I sudo ls -l /usr/local/var/ > > I get > > drwx--. 2 root root 4096 Jul 13 16:09 shishi > > Are those rights correct? > > Many thanks. > > Philroc > > > > ___ > Help-shishi mailing list > Help-shishi@gnu.org > https://lists.gnu.org/mailman/listinfo/help-shishi ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Shishi interop server running
All, I have setup a Shishi KDC for interop purposes on interop.josefsson.org. The server is running Ubuntu 12.04 with Shishi installed from packages. The machine configuration is public, Shishi specific parts are here: https://www.gitorious.org/cosmos/sjd-cosmos/blobs/master/interop.josefsson.org/pre-tasks.d/910shishi https://www.gitorious.org/cosmos/sjd-cosmos/blobs/master/interop.josefsson.org/post-tasks.d/920shishi You can test it by invoking 'shishi u...@interop.josefsson.org' as a client. The password is 'pencil'. Of course, MIT/Heimdal clients should work as well. See simple transcript here: jas@latte:~$ shishi u...@interop.josefsson.org Enter password for `u...@interop.josefsson.org': u...@interop.josefsson.org: Authtime: Wed Aug 8 15:03:14 2012 Endtime:Wed Aug 8 23:03:12 2012 Server: krbtgt/interop.josefsson.org key aes256-cts-hmac-sha1-96 (18) Ticket key: aes256-cts-hmac-sha1-96 (18) protected by aes256-cts-hmac-sha1-96 (18) Ticket flags: INITIAL (512) jas@latte:~$ Or using MIT Kerberos: jas@latte:~$ kinit user Password for u...@interop.josefsson.org: jas@latte:~$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: u...@interop.josefsson.org Valid starting Expires Service principal 2012-08-08 15:04:16 2012-08-09 15:04:14 krbtgt/interop.josefsson@interop.josefsson.org jas@latte:~$ Or using Heimdal: jas@latte:~$ kinit user u...@interop.josefsson.org's Password: jas@latte:~$ klist Credentials cache: FILE:/tmp/krb5cc_1000 Principal: u...@interop.josefsson.org IssuedExpires Principal Aug 8 15:06:42 2012 Aug 9 01:06:38 2012 krbtgt/interop.josefsson@interop.josefsson.org jas@latte:~$ If you want to test a Kerberized client against the server, there is also a telnetd running on the machine, and it accepts Kerberos login for the user 'user' for the principal u...@interop.josefsson.org. The telnetd server is GNU InetUtils, also from Ubuntu packages. To test it on the client side, you can install the 'inetutils-telnet' package on your machine. Put 'default-realm interop.josefsson.org' in your ~/.shishi/shishi.conf to configure Shishi for this realm. Make sure you have tickets (see above) and then try it like this: jas@latte:~$ inetutils-telnet -l user interop.josefsson.org Trying 178.79.173.181... Automatic decryption of input is enabled Automatic encryption of output is enabled Will send login name and/or authentication information. Encryption is verbose Connected to interop.josefsson.org. Escape character is '^]'. [ Kerberos V5 accepts you as ``interop.josefsson.org'' (server authenticated) ] [ Output is now encrypted with type DES_CFB64 ] [ Input is now decrypted with type DES_CFB64 ] ... Connection closed by foreign host. jas@latte:~$ This is with a ~/.telnetrc file that contains: DEFAULT environ export XAUTHORITY set autodecrypt set autoencrypt set autologin # set authdebug set verbose_encrypt Unfortunately, MIT and Heimdal telnet clients doesn't appear to deal with AES keys (sigh!) so you can't connect to it using MIT telnet. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Broken k5login authentication type.
Mats Erik Andersson writes: > onsdag den 8 augusti 2012 klockan 14:11 skrev Simon Josefsson detta: >> Mats Erik Andersson writes: >> > >> > Probably better would be a configuration value like >> > >> > ## etc/shishi/shishi.conf >> > >> > ## Default authorization setting of servers. The default setting >> > ## is "k5login basic", but administrators are urged to check this. >> > ## >> > #authorization-default=k5login basic >> > >> > This would make the library setting transparent and it would increase >> > the awareness of the matter in each administrator using Shishi as their >> > preferred Kerberos support. Including "k5login" probably eases the >> > migration to libshishi in multi-system environments. >> >> That seems nice -- and presumably then we would remove the "k5login >> basic" stuff from InetUtils? > > Removing, or introducing a command line switch to make configurable > for the specific service, thus overriding the site policy? Yup. It would be nice to be able to provide the intended Kerberos realm to the telnet client as well, instead of falling back to 'default-realm'. The less intrusive 'server-realm' should work though, but I didn't get it to work. > In any case it is important that libshishi is consistent and > transparent in itself. Agreed. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Broken k5login authentication type.
Mats Erik Andersson writes: > onsdag den 8 augusti 2012 klockan 13:10 skrev Simon Josefsson detta: >> Mats Erik Andersson writes: >> >> > My preferred interpretation is that >> > >> > shishi_authorize_p (h, "k5login"); >> > >> > should only set authorization type "k5login", nothing more, nothing less. >> > Allowing the fall back is equivalent to make the above call be equal to >> > >> > shishi_authorize_p (h, "k5login basic"); >> > >> > I find it important to be able to enforce a distinction here. >> >> Good point, I agree. >> >> It feels a bit awkward for every application to provide the "k5login >> basic" string though. What if we want to introduce something new by >> default in the future? Maybe there should be a "default" authorization >> string that maps to (currently) "k5login basic". Then most applications >> could use that, and we'd be more future safe. Thoughts? > > For all readers, let me recall that the default effect of > shishi_init_server() is identical to executing > >shishi_authorize_p (h, "basic"); > > Thus authorizing access only for identical remote and local user names. > Each call to shishi_authorize_p() erases the previous setting and > attempts to set new authorization types, so there is no incremental > effect here, which is perfectly desireable. > > An alternative to the present state would be to initialize the server > with both types "basic" and "k5login" in shishi_init_server(). > > Probably better would be a configuration value like > > ## etc/shishi/shishi.conf > > ## Default authorization setting of servers. The default setting > ## is "k5login basic", but administrators are urged to check this. > ## > #authorization-default=k5login basic > > This would make the library setting transparent and it would increase > the awareness of the matter in each administrator using Shishi as their > preferred Kerberos support. Including "k5login" probably eases the > migration to libshishi in multi-system environments. That seems nice -- and presumably then we would remove the "k5login basic" stuff from InetUtils? Thanks, /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Broken k5login authentication type.
Mats Erik Andersson writes: > onsdag den 8 augusti 2012 klockan 12:39 skrev Simon Josefsson detta: >> Mats Erik Andersson writes: >> >> Thank you! Patch applied. >> >> > * No falling back to other authentication types, as this would >> > consitute a security breach in itself. >> >> I think you refer to the case where there is no .k5login file. I recall >> that MIT/Heimdal fall back on a strcmp-like approach in this situation, >> doesn't it? If the file doesn't exist, I think the semantics in >> MIT/Heimdal is that if your principal matches the username, you are let >> in. Please check this and followup. > > My preferred interpretation is that > > shishi_authorize_p (h, "k5login"); > > should only set authorization type "k5login", nothing more, nothing less. > Allowing the fall back is equivalent to make the above call be equal to > > shishi_authorize_p (h, "k5login basic"); > > I find it important to be able to enforce a distinction here. Good point, I agree. It feels a bit awkward for every application to provide the "k5login basic" string though. What if we want to introduce something new by default in the future? Maybe there should be a "default" authorization string that maps to (currently) "k5login basic". Then most applications could use that, and we'd be more future safe. Thoughts? /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Principal name guessing needs LOGNAME.
Mats Erik Andersson writes: > Some known systems, foremost Solaris, do not use the environment > variable USER. Thus the principal name guessing in libshishi > will go astray in OpenSolaris. The remedy is to test also LOGNAME > after investigating USER in shishi_principal_default_guess(). > Patch included! Applied as well, thank you! Btw, please separate doc fix patches from other changes if you can, as it makes finding the LOGNAME/USER fix easier. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Segfaults in authorization type setting.
Mats Erik Andersson writes: > The functions > > shishi_cfg_clientkdcetype_set() > > and > > shishi_cfg_authorizationtype_set() > > are both throwing segmentation faults every time > they are fed with constant value strings. The reason > is that they both depend on strtok_r() which must > be given writeable strings. Simple calls to xstrdup() > resolve this issue. > > As a second matter, both functions always return SHISHI_OK. > This is not reasonable, so a change is implemented that returns > SHISHI_OK whenever at least one valid value was found and set > for the intended configuration entity. Thank you, applied. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Broken k5login authentication type.
Mats Erik Andersson writes: > The present code for the authorization type "k5login" > contains serious security issues, should it have been > possible to activate it. Fortunately, the code does > not even construct the path "$HOME/.k5login" correctly, > so the code will never get into action! > > The present patch addresses "lib/authorize.c" on the following > points of importance: Thank you! Patch applied. > * No falling back to other authentication types, as this would > consitute a security breach in itself. I think you refer to the case where there is no .k5login file. I recall that MIT/Heimdal fall back on a strcmp-like approach in this situation, doesn't it? If the file doesn't exist, I think the semantics in MIT/Heimdal is that if your principal matches the username, you are let in. Please check this and followup. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Bug#670316: shishi: FTBFS on s390x: testsuite failure
> > Sure -- should I just upload to unstable? If you could ask the release > > team that would be great. > > > > Yes, it's just about uploading that to unstable. Then i'll take care of > asking the release team to let it migrate it to wheezy. Thanks -- I've done the upload, let's hope it builds now. :-) /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Bug#670316: shishi: FTBFS on s390x: testsuite failure
mån 2012-07-30 klockan 20:32 +0200 skrev Aurelien Jarno:
> retitle 670316 shishi: FTBFS on 64-bit big endian architecture: testsuite
> failure
> tag 670316 + patch
> thanks
>
> On Wed, Apr 25, 2012 at 03:55:53PM +0200, Philipp Kern wrote:
> > Hi Simon,
> >
> > thanks for the followup.
> >
> > On Wed, Apr 25, 2012 at 02:54:15PM +0200, Simon Josefsson wrote:
> > > Philipp Kern writes:
> > > > your package FTBFSes on s390x because of a crash / failures in the
> > > > testsuite:
> > > >
> > > > make[3]: Leaving directory
> > > > /build/buildd-shishi_1.0.1-1-s390x-luumdM/shishi-1.0.1/tests'
> > > > /usr/bin/make check-TESTS
> > > > make[3]: Entering directory
> > > > /build/buildd-shishi_1.0.1-1-s390x-luumdM/shishi-1.0.1/tests'
> > > > shishi_authenticator_seqnumber_get() failed
> > > > shishi_authenticator_seqnumber_get() failed
> > > > shishi_authenticator_client() failed
> > > > shishi_authenticator_client() failed
> > > > shishi_authenticator_clientrealm() failed
> > > > shishi_authenticator_authorizationdata() failed
> > > > shishi_authenticator_cusec_get() failed
> > > > shishi_authenticator_ctime() failed
> > > > FAIL: authenticator
> > >
> > > Hi. Thanks for the report. I would either need a shell account on this
> > > architecture, or your help in tracking this down. Could you get a gdb
> > > backtrace of the self-test that crashes? Do you have any ideas on what
> > > makes this architecture different from all the others, where it builds
> > > and passes self-tests fine? Does it use the same gcc/glibc/linux
> > > versions as other build hosts?
> >
> > It's 64bit big endian, which isn't the case for all other Debian
> > architectures
> > (except debian-ports ppc64 and sparc64). As a DM you can request guest
> > access
> > yourself by following [1], you don't need anybody to vouch for you or
> > something. If you don't want to do that I can go and collect a backtrace,
> > but
> > it might take a few days, too.
> >
>
> The problem is indeed related to 64-bit big endian machines, it also
> fails to build on ppc64 ans sparc64. This is due to casting size_t
> pointers (len type in shishi) into int pointers (len type in libtasn1).
> The patch below fixes the problem. (Note that there are also plenty of
> format warning about size_t values being printed with %u, though they
> seem to be harmless).
Thanks for debugging this.
>
> Given we are in freeze period, would it be possible to upload a new
> revision of shishi with only these changes? I believe the release team
> would accept such a change and let the package migrate to testing.
> shishi is important on s390x in order to get inetutils built.
Sure -- should I just upload to unstable? If you could ask the release
team that would be great.
/Simon
>
> Regards,
> Aurelien
>
>
> --- shishi-1.0.1.orig/db/file.c
> +++ shishi-1.0.1/db/file.c
> @@ -435,7 +435,7 @@ read_key (Shisa * dbh,
>
>memset (&tmpkey, 0, sizeof (tmpkey));
>
> - rc = fscanf (fh, "%u %u %u %u %u %u", &tmpkey.etype, &tmpkey.keylen,
> + rc = fscanf (fh, "%u %zu %zu %zu %u %u", &tmpkey.etype, &tmpkey.keylen,
> &tmpkey.saltlen, &tmpkey.str2keyparamlen, &passwdlen,
> &tmpkey.priority);
>if (rc != 5 && rc != 6)
> --- shishi-1.0.1.orig/lib/asn1.c
> +++ shishi-1.0.1/lib/asn1.c
> @@ -124,8 +124,10 @@ shishi_asn1_read_inline (Shishi * handle
>const char *field, char *data, size_t * datalen)
> {
>int rc;
> + int tmp = (int) *datalen;
>
> - rc = asn1_read_value (node, field, (unsigned char *) data, (int *)
> datalen);
> + rc = asn1_read_value (node, field, (unsigned char *) data, &tmp);
> + *datalen = tmp;
>if (rc != ASN1_SUCCESS)
> {
>shishi_error_set (handle, asn1_strerror (rc));
>
>
>
___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi
Bug#670316: shishi: FTBFS on s390x: testsuite failure
Philipp Kern writes: > Hi Simon, > > thanks for the followup. > > On Wed, Apr 25, 2012 at 02:54:15PM +0200, Simon Josefsson wrote: >> Philipp Kern writes: >> > your package FTBFSes on s390x because of a crash / failures in the >> > testsuite: >> > >> > make[3]: Leaving directory >> > /build/buildd-shishi_1.0.1-1-s390x-luumdM/shishi-1.0.1/tests' >> > /usr/bin/make check-TESTS >> > make[3]: Entering directory >> > /build/buildd-shishi_1.0.1-1-s390x-luumdM/shishi-1.0.1/tests' >> > shishi_authenticator_seqnumber_get() failed >> > shishi_authenticator_seqnumber_get() failed >> > shishi_authenticator_client() failed >> > shishi_authenticator_client() failed >> > shishi_authenticator_clientrealm() failed >> > shishi_authenticator_authorizationdata() failed >> > shishi_authenticator_cusec_get() failed >> > shishi_authenticator_ctime() failed >> > FAIL: authenticator >> >> Hi. Thanks for the report. I would either need a shell account on this >> architecture, or your help in tracking this down. Could you get a gdb >> backtrace of the self-test that crashes? Do you have any ideas on what >> makes this architecture different from all the others, where it builds >> and passes self-tests fine? Does it use the same gcc/glibc/linux >> versions as other build hosts? > > It's 64bit big endian, which isn't the case for all other Debian architectures > (except debian-ports ppc64 and sparc64). As a DM you can request guest access > yourself by following [1], you don't need anybody to vouch for you or > something. If you don't want to do that I can go and collect a backtrace, but > it might take a few days, too. Thanks, I have asked for guest access to investigate the problem. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Bug#670316: shishi: FTBFS on s390x: testsuite failure
Philipp Kern writes: > Package: shishi > Version: 1.0.1-1 > Severity: important > User: debian-s...@lists.debian.org > Usertags: s390x > > Hi, > > your package FTBFSes on s390x because of a crash / failures in the testsuite: > > make[3]: Leaving directory > /build/buildd-shishi_1.0.1-1-s390x-luumdM/shishi-1.0.1/tests' > /usr/bin/make check-TESTS > make[3]: Entering directory > /build/buildd-shishi_1.0.1-1-s390x-luumdM/shishi-1.0.1/tests' > shishi_authenticator_seqnumber_get() failed > shishi_authenticator_seqnumber_get() failed > shishi_authenticator_client() failed > shishi_authenticator_client() failed > shishi_authenticator_clientrealm() failed > shishi_authenticator_authorizationdata() failed > shishi_authenticator_cusec_get() failed > shishi_authenticator_ctime() failed > FAIL: authenticator Hi. Thanks for the report. I would either need a shell account on this architecture, or your help in tracking this down. Could you get a gdb backtrace of the self-test that crashes? Do you have any ideas on what makes this architecture different from all the others, where it builds and passes self-tests fine? Does it use the same gcc/glibc/linux versions as other build hosts? /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Bug#624088: shishi: Uses deprecated gnutls_certificate_verify_peers
Andreas Metzler writes: > Package: shishi > Version: 1.0.0-2 > Severity: normal > User: ametz...@downhill.at.eu.org > Usertags: deprecated-gnutls-2.12 > > This package is using gnutls_certificate_verify_peers(), a function marked > deprecated in newer stable versions of GnuTLS (>=2.12.x) and removed in > the GnuTLS development version 2.99.1. GnuTLS 2.12.x is already available > in experimental. > > Excerpt from buildlog: > > starttls.c:198:3: warning: 'gnutls_certificate_verify_peers' is > deprecated (declared at /usr/include/gnutls/compat.h:330) > > > Please switch from gnutls_certificate_verify_peers to its successor > gnutls_certificate_verify_peers2 (first included in gnutls stable > release 1.2.0). Hi! I believe this is fixed with Shishi 1.0.1. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Bug#624031: shishi: Uses deprecated _set_priority GnuTLS functions
Andreas Metzler writes: > Package: shishi > Version: 1.0.0-2 > Severity: normal > User: ametz...@downhill.at.eu.org > Usertags: deprecated-gnutls-2.12 > > This package is using some functions which are marked deprecated in > newer versions of GnuTLS (>=2.12.x). (They are not yet removed, though.) > These functions will be removed in future releases. GnuTLS 2.12.x is > already available in experimental. > > Excerpt from buildlog: > > starttls.c:333:3: warning: 'gnutls_kx_set_priority' is deprecated > (declared at /usr/include/gnutls/compat.h:342) > starttls.c:302:3: warning: 'gnutls_kx_set_priority' is deprecated > (declared at /usr/include/gnutls/compat.h:342) > > > The gnutls_*_set_priority family of functions has been marked deprecated > in 2.12.x. These functions have been superceded by > gnutls_priority_set_direct(). The replacement function was added in gnutls > stable release 2.2.0 (released 2007-12-14). This should also be fixed with 1.0.1. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Build failure with GnuTLS 3.0
l...@gnu.org (Ludovic Courtès) writes: > Hello! > > Shishi 1.0.0 fails to build with GnuTLS 3.0.1: ... > Time for a new release? ;-) Hi! I'm hoping 1.0.1 resolves this. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org https://lists.gnu.org/mailman/listinfo/help-shishi
Shishi 1.0.1 released
Shishi is an implementation of the Kerberos 5 network authentication
system. Shishi can be used to authenticate users in distributed
systems. Shishi is part of a GNU system.
* Version 1.0.1 (released 2012-03-12)
** Builds with GnuTLS 3.x.
** minitasn1: Internal copy upgraded to GNU Libtasn1 v2.11.
** Translation updates.
Added Finnish translation, thanks to Jorma Karvonen.
** Update gnulib files. Many internal cleanups and improvements.
** API and ABI modifications:
No changes since last version.
Shishi contains a library ('libshishi') that can be used by application
developers to add support for Kerberos 5. Shishi contains a command
line utility ('shishi') that is used by users to acquire and manage
tickets (and more). The server side, a Key Distribution Center (KDC),
is implemented by 'shishid', and support X.509 authenticated TLS via
GnuTLS. Of course, a manual documenting usage aspects as well as the
programming API is included.
Shishi currently supports AS/TGS exchanges for acquiring tickets,
pre-authentication, the AP exchange for performing client and server
authentication, and SAFE/PRIV for integrity/privacy protected
application data exchanges. The DES, 3DES, ARCFOUR, and AES
cryptographic algorithms are supported.
Shishi aims to be internationalized, thread safe and portable. Shishi
is written in ANSI/ISO C89, and has been ported to numerous platforms,
including most major Unix platforms and Windows, running on devices
including iPAQ handhelds and S/390 mainframes. Shishi can also be cross
compiled to Microsoft Windows using mingw32 and embedded platforms such
as the Motorola Coldfire.
Current work items include improvements on the server (KDC), integration
of initial authentication via OpenPGP using GnuTLS, set-passwd
implementation, and a LDAP backend for the Shisa library used in the KDC
for information storage. Assistance is appreciated on any of these (or
other) items.
The project web page is available at:
https://www.gnu.org/software/shishi/
All manuals are available from:
https://www.gnu.org/software/shishi/manual/
Direct links to the manual:
HTML: https://www.gnu.org/software/shishi/manual/shishi.html
PDF: https://www.gnu.org/software/shishi/manual/shishi.pdf
Direct links to the API Reference manual:
HTML: https://www.gnu.org/software/shishi/reference/
PDF: https://www.gnu.org/software/shishi/reference/shishi.pdf
For code coverage and cyclomatic code complexity charts:
https://www.gnu.org/software/shishi/coverage/
https://www.gnu.org/software/shishi/cyclo/cyclo-shishi.html
If you need help to use Shishi, or want to help others, you are
invited to join our help-shishi mailing list, see:
<https://lists.gnu.org/mailman/listinfo/help-shishi>.
Here are the compressed sources (4.8MB):
ftp://ftp.gnu.org/gnu/shishi/shishi-1.0.1.tar.gz
http://ftp.gnu.org/gnu/shishi/shishi-1.0.1.tar.gz
Here are GPG detached signatures signed using key 0xB565716F:
ftp://ftp.gnu.org/gnu/shishi/shishi-1.0.1.tar.gz.sig
http://ftp.gnu.org/gnu/shishi/shishi-1.0.1.tar.gz.sig
Improving Shishi is costly, but you can help! We are looking for
organizations that find Shishi useful and wish to contribute back. You
can contribute by reporting bugs, improve the software, or donate money
or equipment.
Commercial support contracts for Shishi are available, and they help
finance continued maintenance. Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding Shishi
maintenance. We are always looking for interesting development
projects. See http://josefsson.org/ for more details.
The software is cryptographically signed by the author using an OpenPGP
key identified by the following information:
pub 1280R/B565716F 2002-05-05 [expires: 2013-05-10]
Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F
uid Simon Josefsson
sub 1280R/4D5D40AE 2002-05-05 [expires: 2013-05-10]
The key is available from:
http://josefsson.org/key.txt
dns:b565716f.josefsson.org?TYPE=CERT
Here are the SHA-1 and SHA-224 checksums:
0e914dbcc27516702acd668929b29c42f850daf5 shishi-1.0.1.tar.gz
96f6eb214fa32a05f4ddb6650ad8ff392b9d36f4fca3a37b8e462e45 shishi-1.0.1.tar.gz
Happy hacking,
Simon
pgpOzHpoLgAXT.pgp
Description: PGP signature
___
Help-shishi mailing list
Help-shishi@gnu.org
https://lists.gnu.org/mailman/listinfo/help-shishi
Re: Debian, OpenSSH, GSSAPI
Oliver Schmidt writes: > Hi, > > I'm currently experimenting with Shishi and tried to authenticate to > an OpenSSH server via Shishi and GSSAPI. I'm not using Gnu SASL, so I > didn't expect it to work out but I wanted to see how far it would > work. > > At first, I missed creating a keytab file. But when I had created it, > I could see in the errors from OpenSSH that it must have recognized it > somehow. Otherwise, I didn't expect that reading the Shishi keytab > would work... Hi and welcome! > Are Shishi keytabs already supported in Debian Linux? Only indirectly -- you need to run 'keytab2shishi' manually to convert MIT/Heimdal ticket files to Shishi files. Adding the support to Shishi to read keytabs/ccache files automatically shouldn't be too difficult, but I have never gotten around to do it. (GNU SASL shouldn't be necessary to get OpenSSH to work.) /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
dpkg packages on gitorious
Simon Josefsson writes: > I haven't pushed the Shishi debian packages yet, but will do as soon as > I find the *.dsc for your latest upload. Now shishi-dpkg is available from gitorious too. In case anyone else missed what we did, we have moved the debian packaging source code to git and it is now hosted at: https://gitorious.org/gss /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Bug#620717: shishi: la file contains non-empty dependency_libs
Russ Allbery writes: > Simon Josefsson writes: > >> Hi Russ. I noticed you fixed some things in CVS for the Shishi package, >> are you planning to upload that one too? That would be great. Once >> that is done, I can import the lenny, squeeze, and your recent upload >> into git and upload that to gitorious too, and we continue from there. > > Yeah, it just went through. Sorry about the delay there; I got caught up > in other things yesterday and forgot about it. You are too quick since I didn't notice any delay. :-) Btw, what is your gitorious account? I'll add you to the debian-gss-shishi gitorious team. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Bug#620717: shishi: la file contains non-empty dependency_libs
Hi Russ. I noticed you fixed some things in CVS for the Shishi package, are you planning to upload that one too? That would be great. Once that is done, I can import the lenny, squeeze, and your recent upload into git and upload that to gitorious too, and we continue from there. Thanks, /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#620717: shishi: la file contains non-empty dependency_libs
Russ Allbery writes: > Simon Josefsson writes: >> Simon Josefsson writes: > >>> I suspect it may be the other way around, but was too tired. I have >>> uploaded gss with your fix now (but I forgot to close the bug through >>> changelog...). I'll wait a day or two and then fix Shishi too. > >> The debian copy of my PGP key had expired, the upload is now pending > > Want me to do the upload, Simon? (If so, anything special I need to know, > or just update CVS and build and upload?) Yes, if you have time please do the upload. Thanks! Everything should be in CVS; if you find any issue go ahead and fix it. Which reminds me, now that squeeze is out, we should move the debian repository to git, and maybe replace cdbs... I will move the repository to git ASAP since that will make things easier for me. But I'll probably not have a lot of cycles to replace cdbs -- I don't care strongly enough; cdbs has "just worked" for me. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#620717: shishi: la file contains non-empty dependency_libs
Simon Josefsson writes: > I suspect it may be the other way around, but was too tired. I have > uploaded gss with your fix now (but I forgot to close the bug through > changelog...). I'll wait a day or two and then fix Shishi too. The debian copy of my PGP key had expired, the upload is now pending http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620872 /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#620717: shishi: la file contains non-empty dependency_libs
Andreas Metzler writes: > On 2011-04-03 Simon Josefsson wrote: > [...] >> The only other package seems to be gss, which we were planning on >> uploading a new package soon for given your other bug report. Should I >> apply this patch to Shishi first, upload it and then wait a few days and >> then upload the newly patched gss? Then gss would no longer refer to >> libshishi.la, right? Then we could finally patch Shishi's debian/ to >> just drop the .la file completely. It is late so I may confused >> something, so please proof-read. :-) > [...] > > Hello Simon, > > I think it needs to happen the other way round: > > #1 Fix gss, removing the la file (#610141) > #2 wait until it is built. > #3 Upload shishi without la files. I suspect it may be the other way around, but was too tired. I have uploaded gss with your fix now (but I forgot to close the bug through changelog...). I'll wait a day or two and then fix Shishi too. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#620717: shishi: la file contains non-empty dependency_libs
Andreas Metzler writes:
> Package: shishi
> Version: 1.0.0-1
> Severity: normal
> Tags: patch
>
> The la files in shishi's development packages contain non-empty
> dependency_libs. Please empty them. The la files cannot be simply
> removed yet because they are refered to in other packages. [1]
The only other package seems to be gss, which we were planning on
uploading a new package soon for given your other bug report. Should I
apply this patch to Shishi first, upload it and then wait a few days and
then upload the newly patched gss? Then gss would no longer refer to
libshishi.la, right? Then we could finally patch Shishi's debian/ to
just drop the .la file completely. It is late so I may confused
something, so please proof-read. :-)
Thanks,
/Simon
> Patch attached.
>
> cu andreas
>
> http://wiki.debian.org/ReleaseGoals/LAFileRemoval
> http://lists.debian.org/debian-devel/2009/08/msg00808.html
> [1] http://release.debian.org/~aba/la/current.txt
>
> diff -Nru shishi-1.0.0/debian/changelog shishi-1.0.0/debian/changelog
> --- shishi-1.0.0/debian/changelog 2010-05-20 21:10:30.0 +0200
> +++ shishi-1.0.0/debian/changelog 2011-04-03 18:28:17.0 +0200
> @@ -1,3 +1,11 @@
> +shishi (1.0.0-1.1) unstable; urgency=low
> +
> + * Non-maintainer upload.
> + * Empty dependency_libs in libtool la file.
> +http://wiki.debian.org/ReleaseGoals/LAFileRemoval
> +
> + -- Andreas Metzler Sun, 03 Apr 2011 18:23:28 +0200
> +
> shishi (1.0.0-1) unstable; urgency=low
>
>* New upstream version.
> diff -Nru shishi-1.0.0/debian/rules shishi-1.0.0/debian/rules
> --- shishi-1.0.0/debian/rules 2010-04-14 12:54:37.0 +0200
> +++ shishi-1.0.0/debian/rules 2011-04-03 18:27:51.0 +0200
> @@ -20,3 +20,7 @@
> # Build manual.
> common-install-prehook-indep:: common-install-prehook-impl
> cd doc && $(MAKE) install-ps install-pdf install-html
> DESTDIR=$(DEB_DESTDIR)
> +
> +common-install-arch::
> + find debian/tmp/usr/lib -name "*.la" -exec \
> + sed -i -e "s,^dependency_libs=.*,dependency_libs=''," {} +
>
> ___
> Help-shishi mailing list
> Help-shishi@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-shishi
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#619229: cross-building support for shishi
Steve Langasek writes: > Hi guys, > > Peter Pearse has prepared a patch for the shishi > package that allows it to cross-build when its build-dependencies are > installed to the usual cross-compiler paths, /usr/$triplet rather than /usr. > This patch has been applied to the shishi package in Ubuntu; you may wish to > apply it in Debian as well. Hi Steve. I have applied the patch to the CVS repository, it will be part of the next upload. Thanks, /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
GNU Network Security Labyrinth
Hi folks, I'm going to be at FOSDEM and give a talk in the GNU DevRoom about network security technologies and their GNU implementation. It will cover (at least) SASL, Kerberos, GSS-API, and TLS. On Saturday 16:20-16:50 in H.2214. http://fosdem.org/2011/schedule/event/gnusecurity See you there! :) /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Windows build
Jeff Blaine writes: >> FWIW, building under Cygwin works, but the resulting shishi >> does not properly parse etc/shishi/shishi.conf > > Hmm, I answered my own question. No, it doesn't work with > libidn installed either. Libidn only matters for non-ascii username/passwords, so it wouldn't explain issues like this. > Note that it completely ignores the realm-kdc line of the > config file, but DOES pick up the default-realm ... weird. Yes, I think you identified the problem. > realm-kdc=PROJ1.OUR.ORG,proj1-kdc.our.org ... > KDCs for realm PROJ1.OUR.ORG: > KDCs for realm PROJ1.OUR.ORG: Your config looks fine. The two lines here indicate something strange is going on. When I test your config file on a debian box I get this: KDCs for realm PROJ1.OUR.ORG: Transport UDP host proj1-kdc.our.org port (null) If you can debug what is happening in lib/cfg.c (search for 'case REALM_KDC_OPTION') that would really help. It could be a problem with 'getsubopt' under Windows. Maybe the gnulib module isn't kicking in properly, or there is a bug in it. Glibc systems have getsubopt built in. Maybe there is some CRLF issue? As far as I can tell, it should ignore both \r and \n but at least worth debugging further if you can easily rewrite the file with different EOL encodings. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: 1.0.0 not on alpha.gnu.org
Jeff Blaine writes: > On 10/25/2010 8:14 PM, Simon Josefsson wrote: >> Jeff Blaine writes: >> >>> Unless I am blind, I do not see 1.0.0 on the FTP server ? >>> >>> "The releases are distributed from ftp://alpha.gnu.org/pub/gnu/shishi/"; >> >> Since the 1.0.0 stable release, is is distributed from >> ftp://ftp.gnu.org/gnu/shishi/ -- but I may have forgotten to update some >> documentation somewhere. Where did you read the above text? > > http://www.gnu.org/software/shishi/ Thanks! Fixed now. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Windows build
Jeff Blaine writes: > What kind of environment do I need to establish to > build Shishi on Windows? Debian with MinGW-W64 works fine here. See 'Building GNU SASL for Windows' at this link: http://josefsson.org/gsasl4win/ for a recipe to build a MinGW cross-compiler easily. You can use that to build Shishi for Windows too. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: 1.0.0 not on alpha.gnu.org
Jeff Blaine writes: > Unless I am blind, I do not see 1.0.0 on the FTP server ? > > "The releases are distributed from ftp://alpha.gnu.org/pub/gnu/shishi/"; Since the 1.0.0 stable release, is is distributed from ftp://ftp.gnu.org/gnu/shishi/ -- but I may have forgotten to update some documentation somewhere. Where did you read the above text? /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: Shishi Version 1.0.0 on Ubuntu Lucid?
Richard Kerver writes: > Version 1.0.0 of Shishi was released 2010-05-20, taking Shishi out of alpha > testing. My Ubuntu Lucid 10.04 repository shows the latest version as > 0.0.40-2. When might I expect a new build for version 1.0.0? Thanks for > the kindness of a response. Regards. Richard. Debian has 1.0.0 in testing so it should only be a matter of syncing that package into Ubuntu. I hope the Ubuntu people can help with this. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Shishi 1.0.0
Shishi is an implementation of the Kerberos 5 network authentication
system. Shishi can be used to authenticate users in distributed
systems. Shishi is part of a GNU system.
* Version 1.0.0 (released 2010-05-20)
** doc: Added PDF version of API reference manual.
See doc/reference/shishi.pdf.
** doc: Added Cyclomatic Code Complexity charts.
See doc/cyclo/.
** build: Fix building with --disable-starttls.
Reported by Johan van Selst in
<http://lists.gnu.org/archive/html/help-shishi/2010-04/msg0.html>.
** minitasn1: Internal copy upgraded to GNU Libtasn1 v2.6.
** Doc fixes.
** API and ABI modifications:
No changes since last version.
Shishi contains a library ('libshishi') that can be used by
application developers to add support for Kerberos 5. Shishi contains
a command line utility ('shishi') that is used by users to acquire and
manage tickets (and more). The server side, a Key Distribution Center
(KDC), is implemented by 'shishid', and support X.509 authenticated
TLS via GnuTLS. Of course, a manual documenting usage aspects as well
as the programming API is included.
Shishi currently supports AS/TGS exchanges for acquiring tickets,
pre-authentication, the AP exchange for performing client and server
authentication, and SAFE/PRIV for integrity/privacy protected
application data exchanges. The DES, 3DES, ARCFOUR, and AES
cryptographic algorithms are supported.
Shishi aims to be internationalized, thread safe and portable. Shishi
is written in ANSI/ISO C89, and has been ported to numerous platforms,
including most major Unix platforms and Windows, running on devices
including iPAQ handhelds and S/390 mainframes. Shishi can also be
cross compiled to Microsoft Windows using mingw32 and embedded
platforms such as the Motorola Coldfire.
Current work items include improvements on the server (KDC),
integration of initial authentication via OpenPGP using GnuTLS,
set-passwd implementation, and a LDAP backend for the Shisa library
used in the KDC for information storage. Assistance is appreciated on
any of these (or other) items.
The project web page is available at:
http://www.gnu.org/software/shishi/
All manuals are available from:
http://www.gnu.org/software/shishi/manual/
Direct links to the manual:
HTML: http://www.gnu.org/software/shishi/manual/shishi.html
PDF: http://www.gnu.org/software/shishi/manual/shishi.pdf
Direct links to the API Reference manual:
HTML: http://www.gnu.org/software/shishi/reference/
PDF: http://www.gnu.org/software/shishi/reference/shishi.pdf
For code coverage and cyclomatic code complexity charts:
http://www.gnu.org/software/shishi/coverage/
http://www.gnu.org/software/shishi/cyclo/cyclo-shishi.html
If you need help to use Shishi, or want to help others, you are
invited to join our help-shishi mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-shishi>.
Here are the compressed sources (4.8MB):
ftp://ftp.gnu.org/gnu/shishi/shishi-1.0.0.tar.gz
http://ftp.gnu.org/gnu/shishi/shishi-1.0.0.tar.gz
Here are GPG detached signatures signed using key 0xB565716F:
ftp://ftp.gnu.org/gnu/shishi/shishi-1.0.0.tar.gz.sig
http://ftp.gnu.org/gnu/shishi/shishi-1.0.0.tar.gz.sig
Improving Shishi is costly, but you can help! We are looking for
organizations that find Shishi useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.
Commercial support contracts for Shishi are available, and they help
finance continued maintenance. Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding Shishi
maintenance. We are always looking for interesting development
projects. See http://josefsson.org/ for more details.
The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:
pub 1280R/B565716F 2002-05-05 [expires: 2011-03-30]
Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F
uid Simon Josefsson
uid Simon Josefsson
sub 1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30]
The key is available from:
http://josefsson.org/key.txt
dns:b565716f.josefsson.org?TYPE=CERT
Daily builds of the package are available from:
http://daily.josefsson.org/shishi/
Here are the build reports for various platforms:
http://autobuild.josefsson.org/shishi/
Here are the SHA-1 and SHA-224 checksums:
076626b59459cbf34f2f5837cc9e482787889fe9 shishi-1.0.0.tar.gz
c9ba1ca6d92cd98374c0a358b64e09eed2fcd6983c63fc11c7bfb72b shishi-1.0.0.tar.gz
Happy hacking,
Simon
pgp7efTc57tSf.pgp
Description: PGP signature
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
GNU Libtasn1 2.6
GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. GNU Libtasn1 is used by GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos V5 structures. NOTE! Future release announcements will not be cross-posted to help-gnutls, gnutls-devel or help-shishi. Please subscribe to info-gnu or join our new mailing list help-libtasn1: http://lists.gnu.org/mailman/listinfo/info-gnu http://lists.gnu.org/mailman/listinfo/help-libtasn1 * Noteworthy changes in release 2.6 (2010-04-20) [stable] - Fix build failure on platforms without support for GNU LD version scripts. - libtasn1: Simplified implementation of asn1_check_version. - tests: Improved self-checks. - Update gnulib files, fix many syntax-check nits, indent code, fix license templates. Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.7MB): ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.6.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.6.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.6.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.6.tar.gz.sig A ZIP archive containing the Windows binaries (268KB): http://josefsson.org/gnutls4win/libtasn1-2.6.zip http://josefsson.org/gnutls4win/libtasn1-2.6.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.6-1_all.deb Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-libtasn1 mailing list, see: http://lists.gnu.org/mailman/listinfo/help-libtasn1 All manuals are available from: http://www.gnu.org/software/libtasn1/manual/ Specifically, the following formats are available. The main manual: HTML: http://www.gnu.org/software/libtasn1/manual/libtasn1.html PDF: http://www.gnu.org/software/libtasn1/manual/libtasn1.pdf API Reference manual: http://www.gnu.org/software/libtasn1/reference/ - GTK-DOC HTML For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: http://www.gnu.org/software/libtasn1/cyclo/ Also useful are code coverage charts which indicate parts of the source code that needs to be tested better by the included self-tests: http://www.gnu.org/software/libtasn1/coverage/ The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2011-03-30] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: dd02f3c8aaa0a1500d65c1e4ae690b76085f621e libtasn1-2.6.tar.gz ba6d50d1e7340f8d1ce07880381afd990ea700c6c4c1cacdba0c2ffd libtasn1-2.6.tar.gz a53c27e245c31be7bdf340dc7ec89cafb758c715 libtasn1-2.6.zip ecbdb08988c28041b98a2373b43fda47cc459d4116719f96cf8f3e76 libtasn1-2.6.zip db5400688eff7c36c3f0baa57f13afda842d665b mingw32-libtasn1_2.6-1_all.deb 7a446b8404e715abb2ec1a24dbe38d3a54169537ad4172ddbf62afdb mingw32-libtasn1_2.6-1_all.deb Happy hacking, Simon pgpPc1EiXIFjD.pgp Description: PGP signature ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: [patch] shishi 0.0.43 compilation error
Johan van Selst writes: > Greetings, > > Compilation of shishi 0.0.43 fails if running with --disable-starttls. > The problem is that even though lib/starttls.c is not compiled, a > function from that file is still referenced elsewhere. > > The patch seems pretty simple (it might well be in the repository > already, but right now I cannot access the git server). So I'll just > send my solution for reference. Hi Johan. Thanks for the report, I guess I rarely test with --disable-starttls. Fixed in git now, and will be part of upcoming 1.0.0 release. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Shishi 0.0.43 (release candidate for 1.0.0)
Shishi is an implementation of the Kerberos 5 network authentication
system. Shishi can be used to authenticate users in distributed
systems. Shishi is part of a GNU system.
Note that we plan to release version 1.0.0 soon and this release
should be regarded as a release candidate. Shishi has been relatively
stable for a long period of time, so it deserves a non-alpha release.
* Version 0.0.43 (released 2010-03-30)
** libshishi, shishid: Make IPv6 support work.
** shishid: Add --no-tls parameter to disable TLS support.
** libshishi, shishid: STARTTLS extension negotiation now follows RFC 5021.
** doc: Fix spelling typos noticed by lintian.
** Update gnulib files.
Including moving the 'stat' module from db/ to gl/ so that libshishi
builds properly.
** API and ABI modifications:
No changes since last version.
Shishi contains a library ('libshishi') that can be used by application
developers to add support for Kerberos 5. Shishi contains a command
line utility ('shishi') that is used by users to acquire and manage
tickets (and more). The server side, a Key Distribution Center (KDC),
is implemented by 'shishid', and support X.509 authenticated TLS via
GnuTLS. Of course, a manual documenting usage aspects as well as the
programming API is included.
Shishi currently supports AS/TGS exchanges for acquiring tickets,
pre-authentication, the AP exchange for performing client and server
authentication, and SAFE/PRIV for integrity/privacy protected
application data exchanges. The DES, 3DES, ARCFOUR, and AES
cryptographic algorithms are supported.
Shishi aims to be internationalized, thread safe and portable. Shishi
is written in ANSI/ISO C89, and has been ported to numerous platforms,
including most major Unix platforms and Windows, running on devices
including iPAQ handhelds and S/390 mainframes. Shishi can also be cross
compiled to Microsoft Windows using mingw32 and embedded platforms such
as the Motorola Coldfire.
Current work items include improvements on the server (KDC), integration
of initial authentication via OpenPGP using GnuTLS, set-passwd
implementation, and a LDAP backend for the Shisa library used in the KDC
for information storage. Assistance is appreciated on any of these (or
other) items.
The project web page is available at:
http://www.gnu.org/software/shishi/
All manuals are available from:
http://www.gnu.org/software/shishi/manual/
Specifically, the following formats are available.
The main manual:
http://www.gnu.org/software/shishi/manual/shishi.html - HTML format
http://www.gnu.org/software/shishi/manual/shishi.pdf - PDF format
API Reference manual:
http://www.gnu.org/software/shishi/reference/ - GTK-DOC HTML
Also useful are code coverage charts which indicate parts of the source
code that needs to be tested better by the included self-tests:
http://www.gnu.org/software/shishi/coverage/
If you need help to use Shishi, or want to help others, you are
invited to join our help-shishi mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-shishi>.
Here are the compressed sources (4.1MB):
ftp://alpha.gnu.org/gnu/shishi/shishi-0.0.43.tar.gz
http://alpha.gnu.org/gnu/shishi/shishi-0.0.43.tar.gz
Here are GPG detached signatures signed using key 0xB565716F:
ftp://alpha.gnu.org/gnu/shishi/shishi-0.0.43.tar.gz.sig
http://alpha.gnu.org/gnu/shishi/shishi-0.0.43.tar.gz.sig
We also provide pre-built Windows binaries:
http://josefsson.org/gnutls4win/shishi-0.0.43.zip
http://josefsson.org/gnutls4win/mingw32-shishi_0.0.43-1_all.deb
Improving Shishi is costly, but you can help! We are looking for
organizations that find Shishi useful and wish to contribute back. You
can contribute by reporting bugs, improve the software, or donate money
or equipment.
Commercial support contracts for Shishi are available, and they help
finance continued maintenance. Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding Shishi
maintenance. We are always looking for interesting development
projects. See http://josefsson.org/ for more details.
The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:
pub 1280R/B565716F 2002-05-05 [expires: 2011-03-30]
Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F
uid Simon Josefsson
uid Simon Josefsson
sub 1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30]
The key is available from:
http://josefsson.org/key.txt
dns:b565716f.josefsson.org?TYPE=CERT
Daily builds of the package are available from:
http://daily.josefsson.org/shishi/
Here are the build reports for various platforms:
http://autobuild.josefsson.org/shishi/
Here are the SHA-1 and SHA-224 checksums:
43a64c126f3711f32089b84b62a205a162d22ddd shishi-0.0.43.tar.gz
5bc6a30bb79d091e963d872ae75b885afffe11024a3ad37000e0 shishi-0.0.43.tar.gz
be24fbed8
Summer of code projects for GNU
GNU is participating in summer of code this year and I may be able to mentor students doing work for any project I maintain. I'm not going to write up project ideas, but leave that to you (although check the project ideas for 2006 and 2007 for some ideas I have written down). For more information see: http://www.gnu.org/software/soc-projects/ideas-2010.html /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Shishi 0.0.42
Shishi is an implementation of the Kerberos 5 network authentication
system. Shishi can be used to authenticate users in distributed
systems. Shishi is part of a GNU system.
* Version 0.0.42 (released 2010-03-15)
** libshishi: Add APIs to save keys on keytab format.
The functions are shishi_keys_to_keytab_file and
shishi_keys_to_keytab_mem.
** libshishi: Add APIs to retrieve/set the timestamp for a key.
Typically only used by keytab format. The functions are
shishi_key_timestamp and shishi_key_timestamp_set.
** libshishi: Add API to read several keys from a file.
The function is shishi_keys_from_file.
** keytab2shishi: Add --reverse (-R) parameter to write Keytab files.
This allows you to use create Keytab files from your Shishi hostkeys.
** libshishi: Fix bug where '3des' is parsed as 'des'.
** minitasn1: Internal copy upgraded to GNU Libtasn1 v2.5.
** API and ABI modifications:
shishi_key_timestamp: ADD.
shishi_key_timestamp_set: ADD.
shishi_keys_from_file: ADD.
shishi_keys_to_keytab_file: ADD.
shishi_keys_to_keytab_mem: ADD.
Shishi contains a library ('libshishi') that can be used by application
developers to add support for Kerberos 5. Shishi contains a command
line utility ('shishi') that is used by users to acquire and manage
tickets (and more). The server side, a Key Distribution Center (KDC),
is implemented by 'shishid', and support X.509 authenticated TLS via
GnuTLS. Of course, a manual documenting usage aspects as well as the
programming API is included.
Shishi currently supports AS/TGS exchanges for acquiring tickets,
pre-authentication, the AP exchange for performing client and server
authentication, and SAFE/PRIV for integrity/privacy protected
application data exchanges. The DES, 3DES, ARCFOUR, and AES
cryptographic algorithms are supported.
Shishi aims to be internationalized, thread safe and portable. Shishi
is written in ANSI/ISO C89, and has been ported to numerous platforms,
including most major Unix platforms and Windows, running on devices
including iPAQ handhelds and S/390 mainframes. Shishi can also be cross
compiled to Microsoft Windows using mingw32 and embedded platforms such
as the Motorola Coldfire.
Current work items include improvements on the server (KDC), integration
of initial authentication via OpenPGP using GnuTLS, set-passwd
implementation, and a LDAP backend for the Shisa library used in the KDC
for information storage. Assistance is appreciated on any of these (or
other) items.
The project web page is available at:
http://www.gnu.org/software/shishi/
All manuals are available from:
http://www.gnu.org/software/shishi/manual/
Specifically, the following formats are available.
The main manual:
http://www.gnu.org/software/shishi/manual/shishi.html - HTML format
http://www.gnu.org/software/shishi/manual/shishi.pdf - PDF format
API Reference manual:
http://www.gnu.org/software/shishi/reference/ - GTK-DOC HTML
Also useful are code coverage charts which indicate parts of the source
code that needs to be tested better by the included self-tests:
http://www.gnu.org/software/shishi/coverage/
If you need help to use Shishi, or want to help others, you are
invited to join our help-shishi mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-shishi>.
Here are the compressed sources (4.1MB):
ftp://alpha.gnu.org/gnu/shishi/shishi-0.0.42.tar.gz
http://alpha.gnu.org/gnu/shishi/shishi-0.0.42.tar.gz
Here are GPG detached signatures signed using key 0xB565716F:
ftp://alpha.gnu.org/gnu/shishi/shishi-0.0.42.tar.gz.sig
http://alpha.gnu.org/gnu/shishi/shishi-0.0.42.tar.gz.sig
Improving Shishi is costly, but you can help! We are looking for
organizations that find Shishi useful and wish to contribute back. You
can contribute by reporting bugs, improve the software, or donate money
or equipment.
Commercial support contracts for Shishi are available, and they help
finance continued maintenance. Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding Shishi
maintenance. We are always looking for interesting development
projects. See http://josefsson.org/ for more details.
The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:
pub 1280R/B565716F 2002-05-05 [expires: 2011-03-30]
Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F
uid Simon Josefsson
uid Simon Josefsson
sub 1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30]
The key is available from:
http://josefsson.org/key.txt
dns:b565716f.josefsson.org?TYPE=CERT
Daily builds of the package are available from:
http://daily.josefsson.org/shishi/
Here are the build reports for various platforms:
http://autobuild.josefsson.org/shishi/
Here are the SHA-1 and SHA-224 checksums:
c231ebe301cc674f1b6dfbe7150efa872cb85146 shishi-0.0.42.tar.gz
a20eb914976a2e6
GNU Libtasn1 2.5
GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. GNU Libtasn1 is used by GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos V5 structures. * Noteworthy changes in release 2.5 (2010-03-15) [stable] - doc: Improve GTK-DOC comments. - misc: Updated gnulib files. Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.7MB): ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz.sig A ZIP archive containing the Windows binaries (264KB): http://josefsson.org/gnutls4win/libtasn1-2.5.zip http://josefsson.org/gnutls4win/libtasn1-2.5.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.5-1_all.deb Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-gnutls mailing list, see: <http://lists.gnu.org/mailman/listinfo/help-gnutls>. All manuals are available from: http://www.gnu.org/software/gsasl/manual/ Specifically, the following formats are available. The main manual: HTML: http://www.gnu.org/software/gsasl/manual/gsasl.html PDF: http://www.gnu.org/software/gsasl/manual/gsasl.pdf API Reference manual: http://www.gnu.org/software/gsasl/reference/ - GTK-DOC HTML For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: http://www.gnu.org/software/gnutls/cyclo/ Also useful are code coverage charts which indicate parts of the source code that needs to be tested better by the included self-tests: http://www.gnu.org/software/gnutls/coverage/ The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2011-03-30] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: e317282a86702fb57133b50199df47a7fcf681ca libtasn1-2.5.tar.gz 69e53bb61f3512aa8d1eb72640778b4adebf6818a4493548cc7faf2d libtasn1-2.5.tar.gz 784faa0f4aff35aee1ac420013a9e47aa4892d12 libtasn1-2.5.zip 98177b4e5cbc3bae34dd7813940bec99c802275c9dd0cb77f06a1d3d libtasn1-2.5.zip a5427f26d051a3ab30a8f5bea0abcdf6d3d83f0f mingw32-libtasn1_2.5-1_all.deb 6e781ec4652f8d3fd58e3742dd19f69804665356c11c50e179ed1756 mingw32-libtasn1_2.5-1_all.deb Happy hacking, Simon pgpjazFxohAaM.pgp Description: PGP signature ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#566748: shishi: FTBFS on GNU/kFreeBSD: undefined reference to `rpl_stat'
Petr Salinger writes: > Hi, > > the bug is inside gnulib usage. > > The configure detects that stat() does not work correctly > on 7.2 kernel and should use gnulib function instead. > But the gnulib module is not linked in libshishi.so > > The problem does not affect linux kernels and will be > workarounded after GNU/kFreeBSD switches to 8.0 kernels. > > The needed moduled is in db/gl/stat.c, but not in gl/ directory. Hi -- thanks for debugging. I know what the solution is (use a separate gnulib directory for db/) but it requires a bit of work... it affects other platforms as well, so it is good to fix. Is there any chance that squeeze will use the freebsd 8.0 kernel instead, which (apparently) would make this problem go away? /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#556345: FTBFS with binutils-gold
Peter Fritzsche writes: > Tried to build your package and it fails to build with GNU binutils-gold. The > important difference is that --no-add-needed is the default behavior of of GNU > binutils-gold. Please provide all needed libraries to the linker when building > your executables. ... > /usr/bin/ld: ../lib/.libs/libshishi.so: error: undefined reference to > 'gpg_strerror' Hi Peter. Thanks for your report. I believe this should be fixed by my recent upload of shishi 0.0.41 to debian. Please test that version and re-open this bug if it doesn't appear to be solved. Regards, /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Shishi 0.0.41
Shishi is an implementation of the Kerberos 5 network authentication
system. Shishi can be used to authenticate users in distributed
systems. Shishi is part of a GNU system.
* Version 0.0.41 (released 2010-01-19)
** Add configuration keyword 'quick-random' to speed up libgcrypt.
** Fix libgcrypt detection (problem with libgpg-error dependency).
** Update many gnulib files.
** minitasn1: Internal copy upgraded to GNU Libtasn1 v2.4.
** API and ABI modifications:
No changes since last version.
Shishi contains a library ('libshishi') that can be used by application
developers to add support for Kerberos 5. Shishi contains a command
line utility ('shishi') that is used by users to acquire and manage
tickets (and more). The server side, a Key Distribution Center (KDC),
is implemented by 'shishid', and support X.509 authenticated TLS via
GnuTLS. Of course, a manual documenting usage aspects as well as the
programming API is included.
Shishi currently supports AS/TGS exchanges for acquiring tickets,
pre-authentication, the AP exchange for performing client and server
authentication, and SAFE/PRIV for integrity/privacy protected
application data exchanges. The DES, 3DES, ARCFOUR, and AES
cryptographic algorithms are supported.
Shishi aims to be internationalized, thread safe and portable. Shishi
is written in ANSI/ISO C89, and has been ported to numerous platforms,
including most major Unix platforms and Windows, running on devices
including iPAQ handhelds and S/390 mainframes. Shishi can also be cross
compiled to Microsoft Windows using mingw32 and embedded platforms such
as the Motorola Coldfire.
Current work items include improvements on the server (KDC), integration
of initial authentication via OpenPGP using GnuTLS, set-passwd
implementation, and a LDAP backend for the Shisa library used in the KDC
for information storage. Assistance is appreciated on any of these (or
other) items.
The project web page is available at:
http://www.gnu.org/software/shishi/
All manuals are available from:
http://www.gnu.org/software/shishi/manual/
Specifically, the following formats are available.
The main manual:
http://www.gnu.org/software/shishi/manual/shishi.html - HTML format
http://www.gnu.org/software/shishi/manual/shishi.pdf - PDF format
API Reference manual:
http://www.gnu.org/software/shishi/reference/ - GTK-DOC HTML
For developers interested in improving code quality, we publish
Cyclomatic code complexity charts that help you find code that may need
review and improvements:
http://www.gnu.org/software/gnutls/cyclo/
Also useful are code coverage charts which indicate parts of the source
code that needs to be tested better by the included self-tests:
http://www.gnu.org/software/gnutls/coverage/
If you need help to use Shishi, or want to help others, you are
invited to join our help-shishi mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-shishi>.
Here are the compressed sources (3.8MB):
ftp://alpha.gnu.org/gnu/shishi/shishi-0.0.41.tar.gz
http://alpha.gnu.org/gnu/shishi/shishi-0.0.41.tar.gz
Here are GPG detached signatures signed using key 0xB565716F:
ftp://alpha.gnu.org/gnu/shishi/shishi-0.0.41.tar.gz.sig
http://alpha.gnu.org/gnu/shishi/shishi-0.0.41.tar.gz.sig
Improving Shishi is costly, but you can help! We are looking for
organizations that find Shishi useful and wish to contribute back. You
can contribute by reporting bugs, improve the software, or donate money
or equipment.
Commercial support contracts for Shishi are available, and they help
finance continued maintenance. Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding Shishi
maintenance. We are always looking for interesting development
projects. See http://josefsson.org/ for more details.
The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:
pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21]
Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F
uid Simon Josefsson
uid Simon Josefsson
sub 1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21]
The key is available from:
http://josefsson.org/key.txt
dns:b565716f.josefsson.org?TYPE=CERT
Daily builds of the package are available from:
http://daily.josefsson.org/shishi/
Here are the build reports for various platforms:
http://autobuild.josefsson.org/shishi/
Here are the SHA-1 and SHA-224 checksums:
0dc1280507b62822af54a13f0c210807697bca40 shishi-0.0.41.tar.gz
68d3963f012bec6210e76f67b4a898b4ff7326bc006a02812f034013 shishi-0.0.41.tar.gz
Happy hacking,
Simon
pgpUy5X4YEnnT.pgp
Description: PGP signature
___
Help-shishi mailing list
Help-shishi@gnu.org
http://lists.gnu.org/mailman/listinfo/help-shishi
GNU Libtasn1 2.4
GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. GNU Libtasn1 is used by GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos V5 structures. * Noteworthy changes in release 2.4 (2010-01-18) [stable] - Doc fixes. - Updated gnulib files. - Clean up copyright notices. Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.5MB): ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.4.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.4.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.4.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.4.tar.gz.sig A ZIP archive containing the Windows binaries (268KB): http://josefsson.org/gnutls4win/libtasn1-2.4.zip http://josefsson.org/gnutls4win/libtasn1-2.4.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.4-1_all.deb Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-gnutls mailing list, see: <http://lists.gnu.org/mailman/listinfo/help-gnutls>. All manuals are available from: http://www.gnu.org/software/gsasl/manual/ Specifically, the following formats are available. The main manual: HTML: http://www.gnu.org/software/gsasl/manual/gsasl.html PDF: http://www.gnu.org/software/gsasl/manual/gsasl.pdf API Reference manual: http://www.gnu.org/software/gsasl/reference/ - GTK-DOC HTML For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: http://www.gnu.org/software/gnutls/cyclo/ Also useful are code coverage charts which indicate parts of the source code that needs to be tested better by the included self-tests: http://www.gnu.org/software/gnutls/coverage/ The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: 8cecbb6335e0294ddbcb3a798f0c61c7a2735f23 libtasn1-2.4.tar.gz 04229d6777d176e09aad870b08b69b29eb8826249046f52521f6c975 libtasn1-2.4.tar.gz bcbef65089c6ea44ff5065e4f933c58e650153a0 libtasn1-2.4.zip b81f7643664975a7de12058b20489d8a489121880101c4b1fb24a115 libtasn1-2.4.zip b99a35e23c9e8d3afc2e7ca808f951d0d00c282d mingw32-libtasn1_2.4-1_all.deb 177f47b46154b56623f5b4e51b747e82b6ee4d646c01ce8f38fb3afb mingw32-libtasn1_2.4-1_all.deb Happy hacking, Simon pgpS1y0TjSGDQ.pgp Description: PGP signature ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#542112: shishi-kdc: Incorrect runlevels in init.d scripts header
Petter Reinholdtsen writes: > [Simon Josefsson] >> What if some service depends on the "shishid" service (not likely >> but maybe possible?). > > There is no package in debian depending on the existing provides, > according to http://lintian.debian.org/~pere/test-20091006.log>. > >> Is this possible: >> >> # Provides: shishi-kdc shishid > > Yes, this is possible. > >> Even if it is possible, and we'd use it, I wonder when it would be safe >> to remove the 'shishid' part. Keeping 'shishid' in the Provides: may >> result in people starting to use it. So maybe it is simpler to just >> change 'shishid' to 'shishi-kdc' and deal with any breakage separately >> now rather than later. > > I agree that this is a better approach, given that no one depend on > that script at the moment. Good -- I have made the change in CVS. I don't think this change is critical, though, so I'll try to get a new release of Shishi out before doing another upload. There are some things in the actual code that I want to fix before squeeze... Thanks, /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#542112: shishi-kdc: Incorrect runlevels in init.d scripts header
I have uploaded the package now but I received a lintian warning during dput (see below). I mistakenly only ran lintian on the source package before the upload... I suppose fixing this is as easy as replacing # Provides: shishid with # Provides: shishi-kdc in /etc/init.d/shishi-kdc but I'm not sure about backwards compatibility. What if some service depends on the "shishid" service (not likely but maybe possible?). Is this possible: # Provides: shishi-kdc shishid Even if it is possible, and we'd use it, I wonder when it would be safe to remove the 'shishid' part. Keeping 'shishid' in the Provides: may result in people starting to use it. So maybe it is simpler to just change 'shishid' to 'shishi-kdc' and deal with any breakage separately now rather than later. I don't think there is any service that would depend on the 'shishid' service being started? /Simon j...@mocca:~/src/shishi-0.0.40$ lintian --pedantic -E -I -i /var/cache/pbuilder/result/shishi_0.0.40-2.dsc j...@mocca:~/src/shishi-0.0.40$ j...@mocca:/var/cache/pbuilder/result$ dput -l ftp-master shishi_0.0.40-2_i386.changes Checking signature on .changes gpg: Signature made Wed 07 Oct 2009 10:18:33 AM CEST using RSA key ID B565716F gpg: Good signature from "Simon Josefsson " gpg: aka "Simon Josefsson " Good signature on /var/cache/pbuilder/result/shishi_0.0.40-2_i386.changes. Checking signature on .dsc gpg: Signature made Wed 07 Oct 2009 10:18:30 AM CEST using RSA key ID B565716F gpg: Good signature from "Simon Josefsson " gpg: aka "Simon Josefsson " Good signature on /var/cache/pbuilder/result/shishi_0.0.40-2.dsc. Package is now being checked with lintian. W: shishi-kdc: init.d-script-does-not-provide-itself /etc/init.d/shishi-kdc N: N:This /etc/init.d script indicates it provides one or more facilities, N:but none of the provided facilities match the name of the init script. N:In certain cases, it may be necessary to not follow that convention, but N:normally init scripts should always provide a facility matching the name N:of the init script. N: N:Refer to http://wiki.debian.org/LSBInitScripts for details. N: N:Severity: normal, Certainty: possible N: dput -l ftp-master shishi_0.0.40-2_i386.changes Uploading to ftp-master (via ftp to ftp.upload.debian.org): Uploading shishi_0.0.40-2.dsc: done. Uploading shishi_0.0.40-2.diff.gz: done. Uploading shishi-common_0.0.40-2_all.deb: done. Uploading shishi-doc_0.0.40-2_all.deb: done. Uploading libshishi0_0.0.40-2_i386.deb: done. Uploading libshisa0_0.0.40-2_i386.deb: done. Uploading shishi_0.0.40-2_i386.deb: done. Uploading shishi-dbg_0.0.40-2_i386.deb: done. Uploading libshishi-dev_0.0.40-2_i386.deb: done. Uploading shisa_0.0.40-2_i386.deb: done. Uploading libshisa-dev_0.0.40-2_i386.deb: done. Uploading shishi-kdc_0.0.40-2_i386.deb: done. Uploading libpam-shishi_0.0.40-2_i386.deb: done. Uploading shishi_0.0.40-2_i386.changes: done. Successfully uploaded packages. j...@mocca:/var/cache/pbuilder/result$ ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#542112: shishi-kdc: Incorrect runlevels in init.d scripts header
Petter Reinholdtsen writes: > [Simon Josefsson] >> Actually I don't see that -- when I install shishi-kdc it creates a >> start symlink in /etc/rc2.d for me. This is on a lenny machine that >> never had shishi-kdc installed before. The same happened on my >> debian testing system. So maybe there isn't a problem? If the >> problem is in sid only, is the shishi-kdc.postinst hack really >> needed? Any shishi-kdc packaged installed on a lenny machine would >> have the start/stop links correct, and upgrades to lenny+1 would >> work. > > The issue is with anyone using dependency based boot sequencing, which > have been available since etch, and now is the default in testing > (since a few days ago) and unstable (since this summer). Ok, I trust you know that the patch solves the problem. Will upload shortly. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#542112: shishi-kdc: Incorrect runlevels in init.d scripts header
Petter Reinholdtsen writes: > To test it, install the package in a sid chroot, see that a stop > symlink is created in /etc/rc2.d/ Actually I don't see that -- when I install shishi-kdc it creates a start symlink in /etc/rc2.d for me. This is on a lenny machine that never had shishi-kdc installed before. The same happened on my debian testing system. So maybe there isn't a problem? If the problem is in sid only, is the shishi-kdc.postinst hack really needed? Any shishi-kdc packaged installed on a lenny machine would have the start/stop links correct, and upgrades to lenny+1 would work. /Simon kniv:/etc# ls */*shishi* shishi/shishi.conf shishi/shishi.skel kniv:/etc# apt-get install shishi-kdc Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libshisa0 Suggested packages: shishi-doc The following NEW packages will be installed: libshisa0 shishi-kdc 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 277kB of archives. After this operation, 549kB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://ftp.se.debian.org lenny/main libshisa0 0.0.37-1 [146kB] Get:2 http://ftp.se.debian.org lenny/main shishi-kdc 0.0.37-1 [131kB] Fetched 277kB in 3s (84.7kB/s) Selecting previously deselected package libshisa0. (Reading database ... 15118 files and directories currently installed.) Unpacking libshisa0 (from .../libshisa0_0.0.37-1_i386.deb) ... Selecting previously deselected package shishi-kdc. Unpacking shishi-kdc (from .../shishi-kdc_0.0.37-1_i386.deb) ... Processing triggers for man-db ... Setting up libshisa0 (0.0.37-1) ... Setting up shishi-kdc (0.0.37-1) ... kniv:/etc# ls */*shishi* default/shishi-kdc rc2.d/S20shishi-kdc rc6.d/K20shishi-kdc init.d/shishi-kdcrc3.d/S20shishi-kdc shishi/shishi.conf rc0.d/K20shishi-kdc rc4.d/S20shishi-kdc shishi/shishi.skel rc1.d/K20shishi-kdc rc5.d/S20shishi-kdc kniv:/etc# ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#542112: shishi-kdc: Incorrect runlevels in init.d scripts header
Petter Reinholdtsen writes: > [Simon Josefsson] >> A patch to implement the preinst/postinst hooks necessary to solve >> upgrades would be really appreciated, as I haven't had time to look >> into that. I'm not experienced with how to test such a patch, help? > > I believe this patch should do the trick, trying to detect the > incorrect state and remove the script to allow debhelper to reinsert > it with the correct runlevel state. Thank you! I'm testing this now. Meanwhile, is it OK to release your script under the GPLv3? My suggestion is to do this: --- copyright.~1.22.~ 2009-04-15 12:42:56.0 +0200 +++ copyright 2009-10-06 17:00:15.0 +0200 @@ -161,11 +161,12 @@ Files: debian/* Copyright: Copyright 2005-2009, Simon Josefsson Copyright: Copyright 2005-2008, Russ Allbery +Copyright: Copyright 2009, Petter Reinholdtsen License: GPL-3+ -The package files were written by Simon Josefsson and Russ -Allbery, and are copyright 2005, 2006, 2007, 2008, 2009, and may -be redistributed and/or modified under the terms of the GNU -General Public License as published by the Free Software +The package files were written by Simon Josefsson, Russ Allbery, +and Petter Reinholdtsen and are copyright 2005, 2006, 2007, 2008, +2009, and may be redistributed and/or modified under the terms of +the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. On Debian systems, the complete text of the GNU General Public License version 3 can be found in the file /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#542112: shishi-kdc: Incorrect runlevels in init.d scripts header
Petter Reinholdtsen writes: > Hi. Any more I can do to get a fix for this into unstable? A patch to implement the preinst/postinst hooks necessary to solve upgrades would be really appreciated, as I haven't had time to look into that. I'm not experienced with how to test such a patch, help? > With the current setting, the service will fail to start in the > default installation which uses runlevel 2, and that could be seen as > a bug with severity serious making the package unfit for release. Right, finding a solution quickly would be nice. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#542112: shishi-kdc: Incorrect runlevels in init.d scripts header
I realized that depending on $time makes sense for shishid, because Kerberos V5 assumes correct time. Added in CVS too. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#542112: shishi-kdc: Incorrect runlevels in init.d scripts header
Petter Reinholdtsen writes: > [Simon Josefsson] >> The patch looks trivially correct to me, so I have applied it. > > Good. Please review the dependencies too, to verify that all the > scripts/service it should start after / stop before are listed as > dependencies. I do not know the package well enough to know if there > are something missing. :) I can't think of any other dependencies. The daemon needs the binary itself (i.e., /usr); /var file system; syslog; and network to be up, but I might have forgotten something. Is there a common list of typical dependencies somewhere? I recall that the LSB section was written for RedHat, which use slightly different semantics (i.e., they support /usr on a remote file system, or at least did at some point). >> Is it worth an upload to fix this? > > I believe so. Everyone installing this package when dependency based > boot sequencing get the init.d scripts inserted into the wrong rc?.d/ > directories, and at the moment dependency based boot sequencing is the > default in Debian/unstabe. Ouch. I'll do an upload soon. >> I'm not sure what the best practice is. > > The best practice is not very good, but it is to remove all rc?.d/ > symlinks during upgrade and reinsert the script symlinks to make sure > the change take effect. This is because of limitations in the > update-rc.d interface. :( Hm. Are you saying just uploading the package with your patch won't be sufficient? Any pointers to other packages with similar problem, and how it was fixed? /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Bug#542112: shishi-kdc: Incorrect runlevels in init.d scripts header
tags 542112 +pending thanks Petter Reinholdtsen writes: > With dependency based boot sequencing, I discovered what I believe is > a bug in the init.d script. The update-rc.d call said it should have > the default settings, while the runlevels listed in the init.d header > do not match this. > > http://refspecs.freestandards.org/LSB_2.1.0/LSB-generic/LSB-generic/initscrcomconv.html > > > documents the LSB header format. Some debian notes are available from > http://wiki.debian.org/LSBInitScripts >. > > This patch should solve the issue, by making sure the init.d script is > started in runlevel 2 by default. The patch looks trivially correct to me, so I have applied it. Is it worth an upload to fix this? I'm not sure what the best practice is. I'm preparing a new upstream release as well, to fix some /dev/*random issues, which would be useful to get into squeeze, so the next upload shouldn't be too long away anyway. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: GNU Libtasn1 2.3
Simon Josefsson writes: > Here are the compressed sources (1.5MB): > ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz > http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz > > Here are GPG detached signatures using key 0xB565716F: > ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig > http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig The correct URLs should be: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz.sig Thanks to Arfrever Frehtes Taifersar Arahesis for noticing this. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
GNU Libtasn1 2.3
I'm happy to announce the first release of Libtasn1 as an official GNU project. GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. Libtasn1 is used by GnuTLS to parse and generate X.509 structures and by Shishi to parse and generate Kerberos V5 structures. * Noteworthy changes in release 2.3 (2009-07-29) [stable] - Libtasn1 is now an official GNU project. - Solve build problem on Tru64 related to TRUE/FALSE. - More careful decoding of OIDs. - Fixed warning in ASN1.y. - Use "Software libraries" info dircategory. - Drop GPL/LGPL copies from the manual (not needed there). - New configure parameters to set packaging specific information. The parameters are --with-packager, --with-packager-version, and --with-packager-bug-reports. See <http://article.gmane.org/gmane.comp.lib.gnulib.bugs/17791> for more details. Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-gnutls mailing list, see: <http://lists.gnu.org/mailman/listinfo/help-gnutls>. Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.5MB): ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig A ZIP archive containing the Windows binaries (268KB): http://josefsson.org/gnutls4win/libtasn1-2.3.zip http://josefsson.org/gnutls4win/libtasn1-2.3.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.3-1_all.deb The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: 71607f846e83849f0722ffdd93247028c9c88384 libtasn1-2.3.tar.gz 0dc935133aa110fc17e0c212ca3c9b446f3da37e5e51ea1c8561c3ec libtasn1-2.3.tar.gz 31d1570b30f9a86850d74e535138f52f8f164179 libtasn1-2.3.zip 623864081339c7ef653d0356d6abadc64e0a799031351277e302c3ef libtasn1-2.3.zip 461ed2aa187cc86780ca0155b08be05401f9a403 mingw32-libtasn1_2.3-1_all.deb 425d98c7b456d120bf103a0fef59eff55f3694a9682ee0bd3240289d mingw32-libtasn1_2.3-1_all.deb Happy hacking, Simon pgpNuUr47atG1.pgp Description: PGP signature ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
Re: PacketCable KDC
Russ Allbery writes: > Simon Josefsson writes: >> ale...@sumix.com writes: > >>> Anybody implemented a PacketCable KDC uses Shishi? Can you help >>> configure KDC for Shishi? > >> I'm not aware of anyone doing this. If you test it, please let us >> know. If you can provide access to a PacketCable client, I would be >> interested in working on making it work (within reason -- it may be >> using a non-standard protocol). > > To fill in some background, since this also came up on the Heimdal list, > PacketCable apparently uses a pre-standardization draft of PKINIT that's > not compatible with the standardized final version. Ah. Shishi does not implement PKINIT at all, so it may be quite some work to make this work -- although given access to PacketCable clients, I would still be interested in looking into it. /Simon ___ Help-shishi mailing list Help-shishi@gnu.org http://lists.gnu.org/mailman/listinfo/help-shishi
