Bug 207805 - Review Request: skey - An S/Key implementation
Review Request: skey - An S/Key implementation
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
Depends On:
  Show dependency treegraph
Reported: 2006-09-23 12:21 EDT by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-12 18:19:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2006-09-23 12:21:51 EDT
Spec URL: http://david.woodhou.se/skey/skey.spec
SRPM URL: http://david.woodhou.se/skey/skey-0.2-8.src.rpm
The S/Key suite is the forerunner of OTP, the IETF One-Time Password
system.  S/Key uses the MD4 (MD5, in this version) algorithm to generate
a list of nonsensical pass phrases using your password, an interation
count, and a seed. 

 $ rpmlint SRPMS/skey-0.2-8.src.rpm RPMS/ppc/skey-0.2-8.ppc.rpm RPMS/ppc/pam_skey-0.2-8.ppc.rpm RPMS/ppc/skey-sshhelper-0.2-8.ppc.rpm RPMS/ppc/skey-debuginfo-0.2-8.ppc.rpm
W: skey no-url-tag
W: skey no-url-tag
E: skey setuid-binary /usr/sbin/skeyinit root 04755
E: skey non-standard-executable-perm /usr/sbin/skeyinit 04755
E: skey non-readable /etc/skeykeys 0600
E: skey zero-length /etc/skeykeys
W: pam_skey no-url-tag
W: skey-sshhelper no-url-tag
W: skey-debuginfo no-url-tag

No appropriate URL to give. skeyinit is intended to be setuid, and skeykeys is intended to be empty.
Comment 1 Jochen Schmitt 2006-09-24 15:32:12 EDT
You rpmlint listing contains some messsages line 'no-url-tag' which vaiolates
the packaging guidelines.

If you may fix it, I will be willing to review your package.

Best Regards:

Jochen Schmitt
Comment 2 David Woodhouse 2006-09-24 15:45:29 EDT
As I said in the original comment, there is no appropriate URL to give. I
suppose I could give 'file:/dev/null' or repeat the download tarball filename,
but that seems strange. The guidelines don't really mandate the presence of a
URL, do they?

I'm looking at http://fedoraproject.org/wiki/Packaging/ReviewGuidelines and
http://fedoraproject.org/wiki/Packaging/Guidelines -- neither of which say that
there must be a URL, unless I'm being particularly dim this evening.

Thanks for the review, btw.
Comment 3 Dominik 'Rathann' Mierzejewski 2006-09-24 19:30:15 EDT
http://www.tux.org/pub/net/olaf-kirch/dontuse/linux-skey.lsm says that the
license of the utils is unknown. This is clearly unacceptable for Fedora. I
personally dislike the presence of the word 'crap' in package summary. What is
the point of packaging this, anyway? This software seems to be ancient. Why is
it located in a directory named 'dontuse'?
Comment 4 Jason Tibbitts 2006-09-25 00:48:36 EDT
There is no requirement for a URL tag; if there is no upstream home page then it
would be pointless to include a URL.

The word "crap" does not appear in the package's summary, just this bugzilla
ticket.  (Check the specfile and you'll see.)

One thing that concerns me is that the software is dated 1999, the upstream
tarball lives in a directory named "dontuse", and the package includes a
root-owned setuid binary.  I'm not competent to evaluate this software for
vulnerabilities, but it would be good to know the potential exposure.

However, the license (or general lack thereof) is indeed troubling, and without
clarification I think this does render this package unacceptable for extras. 
The PAM stuff is indicated to be GPL (but carries no license statement that I
can see), md5.* is public domain, and the rest is pretty much indeterminate.
Comment 5 David Woodhouse 2006-09-25 04:12:54 EDT
Hm, I hadn't noticed the 'unknown' bit in the lsm file -- this is derived from a
package we've had internally for years. I'll ask Olaf about it.

Since the main use for it is the s/key _client_, I could usefully split the
setuid  'skeyinit' and other bits into a separate subpackage -- in fact I don't
even care whether we ship those or not.

Yes, the software's ancient. Nevertheless, some misguided IT departments still
deploy it, such that using the s/key client is the only way to SSH into the
company network.
Comment 6 David Woodhouse 2006-09-25 04:50:59 EDT
The skey files come from Wietse Venema's logdaemon package, where they are
described thus:

These files are modified versions of the s/key files found on
thumper.bellcore.com at 21 oct 1993. They have been fixed to run on
SunOS 4.1.3, Solaris 2.3, Ultrix 4.3 and 44BSD. The original files are
still present, with a "-" tacked onto their name.

The MD4 and MD5 source code was taken from the NRL S/Key distribution
on thumper on Sept 21 1994.  This version is byte-order independent.
Comment 7 David Woodhouse 2006-09-25 05:11:07 EDT
RFC1760 describes the original MD4-based s/key implementation, and states that
the original implementation was released "for public use".

RFC2289 describes the generic version supporting also MD5 and SHA1.

This package supports only MD5.
Comment 8 Jason Tibbitts 2006-09-25 20:18:31 EDT
Given the confusion over the license, perhaps these bits of clarification could
find their way into the package so there's no question later.  (Perhaps I'm
being dense here, but comment #6 seems to incorporate the logdaemon license by
reference.  It might be good to include it as well.)

I agree that it would be good to split the package into skey-clients and
skey-server (or whatever is reasonable) to get the setuid stuff away from what
most people would need to install.  The thought of very old source and setuid
bits makes me pucker, but you're the maintainer so it's your call.
Comment 9 Peter Bieringer 2007-04-05 07:18:25 EDT
Probably related, how about adding at least OPIE support? There are packages
available for Debian, PLD and SuSE but I didn't found one for Fedora/RedHat systems.
Comment 10 Jason Tibbitts 2007-06-16 02:26:48 EDT
So, anything happening here?
Comment 11 Jason Tibbitts 2007-07-08 12:41:35 EDT
No response in three weeks; setting NEEDINFO.  I will close this ticket soon if
there is no further progress.
Comment 12 David Woodhouse 2007-07-12 18:19:14 EDT
Submitted opie instead (just the client parts). Bug 248067

Note You need to log in before you can comment on or make changes to this bug.