Bug#782639: ITP: yubikey-piv-manager -- Graphical tool for managing your PIV-enabled YubiKey
Package: wnpp Severity: wishlist Owner: Dain Nilsson d...@yubico.com * Package name: yubikey-piv-manager Version : 1.0.0 Upstream Author : Dain Nilsson d...@yubico.com * URL : https://developers.yubico.com/yubikey-piv-manager/ * License : GPLv3+ Programming Lang: Python Description : Graphical tool for managing your PIV-enabled YubiKey This tool is used for performing administrative tasks on a PIV-enabled YubiKey. It allows management of PIN, PUK, as well as the Management Key, and can be used to generate and/or import keys and certificates. This is a GUI that wraps yubico-piv-tool, and provides some additional functionality.
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
Chiming in on some of the issues below. *Dain Nilsson* Senior Software Developer, Yubico d...@yubico.com yubico.com On Wed, Oct 15, 2014 at 11:54 AM, Simon Josefsson si...@josefsson.org wrote: I have uploaded a new version of the package to mentors incorporating the changes mentioned below. There is one remaining blocker for this package entering Debian: The libu2f-host0 package is not yet in Debian. I'd love for you two to put your review cycles into it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764262 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764460 Re icons, larger non-XPM ones (including SVG) should be installed in /usr/share/icons/hicolor/widthxheight/apps: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout Thanks -- we are trying to sort this out, either we do something in the Debian packaging or we do it upstream -- but the latter requires some thinking since the package is cross-platform (Windows, Mac, GNU). This sounds fine, I think placing the files in the correct location for the Debian package is best. Some other things you might want to fix: I like to wrap debian/*.menu files at one attribute per line to make diffs more readable. Agreed, done. I like to run wrap-and-sort -sa to wrap the other debian/* files in the same way for the same reason. Didn't know about that tool, thanks for pointer. Ran it without -s though. I think the Priority should be optional rather than extra. Done. I would recommend debian/compat 9 and debhelper 9. Done. The license for neoman/libloader.py seems to be BSD-3-clause not BSD-2-clause? Done. The multiarch handling in neoman/libloader.py is incorrect, it should not hard-code the paths for amd64 and i386, Debian has other 64-bit and 32-bit ports plus the non-Linux ports. The neoman/libloader.py looks at /etc/ld.so.conf but that won't work on multi-arch systems becase /etc/ld.so.conf just includes /etc/ld.so.conf/*.conf and contains no dirs. No idea how to resolve this -- I suppose libloader.py is some external file we copie in, maybe there are Debian-ified versions of it. Dain? Not sure why this package have to hardcode or read ld.so.conf at all. Yes, this code is copied from an external source, I'm not entirely sure why it does some things it does, but it seems to work pretty well and I'm not sure we have the resources to be testing this on a vast number of different distros, so I've refrained from making any changes to this file. I'll open an issue for the upstream package regarding this. The manual page, desktop file and icon(s) should be installed by the upstream build system. PNG might be a better choice for the icons since it provides 8-bit transparency instead of 1-bit transparency. They seem to be PNG's in 0.2.3. Dain, can you install them? The menu icon is XPM now, I thought Debian required these to be XPM? If not then I agree that PNG is better. As for the upstream build system installing the man page, .desktop file and icons, I'm not sure the upstream build system has a good way of doing this. I'll open another issue for this nonetheless. These files look like they were generated from other files, I would suggest removing them from the VCS and tarballs and creating them at build time if possible: resources/installer_bg.png resources/neoman.icns resources/neoman.ico resources/neoman.xpm debian/neoman.xpm neoman/neoman.png It is common to ship generated files in tarballs, to avoid forcing users to have a lot of tools available. Agree with removing them from git though, Dain? debian/neoman.xpm and neoman/neoman.png have already been removed in 0.2.3. All of the resources/* files are manually created. DEFAULT_KEY does not look like something that should be included? Why not? Earlier NEOs had that key as the default (it is the common Visa/Mastercard standard key), although modern NEOs have randomized keys. Are the files listed in neoman/appletdb.json Free Software? Are they required for operation of yubikey-neo-manager? ykneo-oath and ykneo-openpgp are free software, but they are not required for operation and most people will not want or need them. The upstream signing key uses SHA1 for the self-sig, it should be re-signed with a SHA512 self-sig: https://help.riseup.net/en/security/message-security/openpgp/best-practices#self-signatures-should-not-use-sha1 Leave this to Dain :-) uscan doesn't like the upstream signing key unless I move it to debian/upstream/signing-key.asc (see below). Dain? The cowbuilder parts of debian/README.source do not look necessary, lots of folks use sbuild and the cowbuilder docs cover what is mentioned in debian/README.source. Yeah, it is mostly an example and reminder for the people working with the packaging. os.system (in release.py) should be replaced by use of the subprocess module
Bug#765179: RFS: yubikey-neo-manager/0.2.2-1 [ITP] -- YubiKey NEO management graphical user interface
I'm resolving the issue of pixmaps in /usr/lib, as well as replacing the
menuicon with one that is 32x32 as we speak. It looks bad when I test it on
Ubuntu (which uses 48x48), but it seems Ubuntu has an app-install-data
package with higher res icons for all of the included packages, so we can
worry about that later I suppose.
*Dain Nilsson*
Senior Software Developer, Yubico
d...@yubico.com
yubico.com
On Tue, Oct 14, 2014 at 11:54 AM, Simon Josefsson si...@josefsson.org
wrote:
On Mon, 2014-10-13 at 21:35 +0200, Simon Josefsson wrote:
Dear mentors,
I am looking for a sponsor for our package yubikey-neo-manager:
Hello Simon!
Thank you for your help in packaging the yubikey neo manager for
Debian! I've got a few things that might need fixing up for you to
take a look at.
Thank you! Cc'ing Dain who has wrote the project.
- The file neoman/libloader has a different copyright than the rest of
the code, both in license and copyright holder. It needs to be
specified in d/copyright
Good catch! Dain, is it needed? I added it to debian/copyright
meanwhile.
- Do you want debian/* to be copyrighted by Yubico, or should it be
copyrighted by you? (This may or may not be a question for legal
counsel.)
Having debian/* be owned by Yubico is fine, we are the same group of
people working on both upstream and the packaging, and all are bound to
Yubico.
- There are several pixmap files being installed under /usr/lib;
architecture independent files should be installed under /usr/share.
- Icons in the Debian menu system should be 32x32 at the largest -
the /usr/share/pixmap/neoman.xpm, file is 128x128.
Yep, we are trying to figure these two out -- do you happen to know how
to get high-res menu icons? 32x32 is really crappy, and there ought to
be a way to provide a better image.
- There is a substitution variable ${python:Provides}, but there
isn't a substitution variable for that. What are you trying to get
from that?
Likely cut'n'paste issue, I dropped it.
I have built and uploaded a new version to mentors.
Thanks, again, for packaging these tools. I have a NEO on my
keychain, so this definitely caught my eye!
Glad to hear that :-) Btw, are you a DD? If you would be willing to
sponsor this, that would be appreciated.
/Simon
Bug#701103: ITP: libanyevent-yubico-perl -- AnyEvent based Perl module for validating YubiKey OTPs
Package: wnpp Severity: wishlist Owner: Dain Nilsson d...@yubico.com * Package name: libanyevent-yubico-perl Version : 0.9.1 Upstream Author : Yubico Open Source Maintainers ossma...@yubico.com * URL : https://github.com/Yubico/yubico-perl-client * License : BSD-2-clause Programming Lang: Perl Description : AnyEvent based Perl module for validating YubiKey OTPs Perl module for validating YubiKey OTPs (One Time Passwords) against a server running the Yubico Validation Protocol v2.0, such as Yubico's YubiCloud, or a locally installed server. Uses AnyEvent to provide both blocking and non-blocking methods for validation. Though AnyEvent is used internally by the module, the calling code is not required to use it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699530: ITP: yubikey-val -- A YubiKey OTP validation server written in PHP
Package: wnpp Severity: wishlist Owner: Dain Nilsson d...@yubico.com * Package name: yubikey-val Version : 2.20 Upstream Author : Yubico Open Source Maintainers ossma...@yubico.com * URL : https://github.com/Yubico/yubikey-val * License : BSD-2-clause Programming Lang: PHP Description : A YubiKey OTP validation server written in PHP The YubiKey Validation Server is a server that validates Yubikey OTPs. It is written in PHP, for use with web servers such as Apache. The server implements the Yubico API protocol as defined in: http://yubico.com/developers/api/ This server talks to another service for decrypting the OTPs, to avoid storing any AES keys within the validation server. One implementation of this service is yubikey-ksm: https://github.com/Yubico/yubikey-ksm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698839: ITP: yubikey-ksm -- A YubiKey KSM written in PHP
Package: wnpp Severity: wishlist Owner: Dain Nilsson d...@yubico.com * Package name: yubikey-ksm Version : 1.9 Upstream Author : Yubico Open Source Maintainers ossma...@yubico.com * URL : https://github.com/Yubico/yubikey-ksm * License : BSD-2-clause Programming Lang: PHP Description : A YubiKey KSM written in PHP The YubiKey Key Storage Module (YK-KSM) provides a AES key storage facility for use with a YubiKey validation server. The YK-KSM is intended to be run on a locked-down server. This separation allows third parties to keep tight control of the AES keys for their YubiKeys, but at the same time allow external validation servers (e.g., Yubico's) to validate OTPs from these YubiKeys. The YK-KSM was designed to work with yubikey-val-server-php. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
