Spec URL: http://david.woodhou.se/skey/skey.spec SRPM URL: http://david.woodhou.se/skey/skey-0.2-8.src.rpm Description: 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.
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
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.
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'?
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.
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.
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.
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.
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.
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.
So, anything happening here?
No response in three weeks; setting NEEDINFO. I will close this ticket soon if there is no further progress.
Submitted opie instead (just the client parts). Bug 248067