Arch Linux User Repository

The FTP-Server seems offline, as well as the whole cis-app.com domain. Does anyone have an alternative source that doesn't require you to click through the EULA and all that? /edit Discussion here: http://sentineldiscussion.gemalto.com/topic/ftp-download-error /edit @ido: If you still don't want to maintain this, I could do it.

@Scimmia: Thanks for the tip, I've updated to use bsdtar (and added the libarchive dependency to replace rpmextract).

Ah, you're correct. I was going through all packages that have a makedep on rpmextract as it's an almost entirely useless package. In your case, you're better off using bsdtar to extract it, as it's already a dep of pacman and doesn't pull in extra packages.

@Scimmia: Doug, makepkg does not extract contents of RPMs from within tarballs with different names. It didn't have any functionality to extract contents of RPMs at all when I created this PKGBUILD -- if that's changed, I'm all for updating the PKGBUILD. Also, these are not source files. Do you have a SafeNet HASP token? If you do and you would like to take over the package, I can disown it if you'd like. I originally took this over to upgrade it to support the SafeNet token that came with X-Plane, but I haven't had much time to use X-Plane or the token in the past few months. Also, just updated it to 7.51 since I noticed that came out.

Why are you extracting the source files manually? makepkg already does it.

@ido: Thanks for that. Although it looks like you've copied the old (v7.32) sha256sum for the "Sentinel_LDK_RedHat_and_SuSE_RPM_Run-time_Installer.tar.gz" file. The JoinsNamespaceOf might be good enough for the /tmp issue alone, leaving the network thing for the moment? I'll give it a go when I get some time. In a few use cases PrivateNetwork may be impossible anyway; with network HASPs and the special developer HASP key (which allows compiling new HASP libs and doing the envelope-protection stuff), multiple hasplmds on multiple machines need to communicate with each other over the local network. I'd be happy to help out where I can. However (I'm hoping) in the near future the software we develop will be able to stop using these damned things entirely :)

@xwhatsit: Thank you for catching that. I tried adding a JoinsNamespaceOf=aksusbd.service directive to the [Unit] section of winehasp.service and hasplmd.service - that solved the detection problem (so the HASP device shows up), but required me to "sudo nsenter -t `pgrep aksusbd` -n -m" (i.e. join the aksusbd process's network and mount namespaces) to use the web admin and to use the LM API's socket in /tmp/.aksusb for communicating with the hardware...which seems like too much of a hassle just for using X-Plane. :-) For now I've removed PrivateTmp and PrivateNetwork. Update and it should be fixed. When I have time to, I would like to move these binaries to run as a non-root user, at a minimum, and make the /tmp/.aksusb socket accessible to console users only. BTW, are you interested in co-maintaining this package?

@ido: The latest package (7.40-1) doesn't seem to work properly with a HASP HL USB key. My software could not access the license manager. I couldn't access the web config GUI through http://localhost:1947 either (which hasplmd also serves up). Through some experimentation I found commenting out "PrivateNetwork" in hasplmd.service allowed me to access the web service. I'm a bit puzzled about this because the systemd docs I read seem to say the loopback device isn't affected, but there you go. I then discovered that the local HASP HL key that was plugged into the system wasn't listed; commenting out "PrivateTmp" in both hasplmd.service *and* aksusbd.service fixed this. This seems to be because a Unix domain socket /tmp/.aksusb is used for communication between aksusbd and hasplmd, perhaps? It's a shame if we can't have these nice features turned on to try and beef up some security against some binaries that we have no source for. It would seem we can't do without having PrivateTmp disabled, but not sure about PrivateNetwork. This coincided with an upgrade to kernel 4.7.0, but not sure if related.

I just rewrote the PKGBUILD, updated to 7.40, fixed the post-install message, and got rid of the PHYSDEVBUS udev errors by removing the redundant legacy udev rules. If you use this package, please comment here confirming that it works for you and remember to vote for the package!