Open alannz42 opened 3 weeks ago
Any software "lock" like a S63 user permit tries to identify the computer the lock belongs to so to speak. The problem is that Flatpak runs in a sandbox, sort of a virtual machine, and the permit thus deems the Flatpak sandbox as another computer than when running without Flatpak.
This is documented in the Flatpak FAQ for o-charts. For these, the vendor is willing to discuss transfer of licenses from "bare metal" to Flatpak on a case by case basis. I actually don't see any other solution for your S63 permit. I understand that this might be hard, sorry.
The long term solution would be that the software lock developers teaches it it handle the Flatpak sandbox. However, this is not trivial and might take a long time.
Relabeling this as an Enhancement since this actually isn't an unexpected behaviour, it's a known thing. Perhaps we should mention S63 user permits together with the o-charts licenses in the FAQ, though.
EDIT: The actual bug here is in the S63 user permit software implementation. However, I don't know how meaningful it would be to report it.
The long term solution would be that the software lock developers teaches it it handle the Flatpak sandbox
Another solution would be that the vendor did the same thing as o-charts and supported a hardware dongle. For o-charts, the dongle works the same way on Flatpak or native packages; S63 would be the same. A quick google shows that this already had been discussed, a dongle also means that the permit can be used on multiple computers which is Good Thing.
For S-63 you have 5 installs - so just create a new InstallPermit for the "Flatpack" device. For that reason we did discard to use the dongle for S-63. Virtual Machines are always an individual device, different from the host. The license (and the FAQs) states that VMs are not supported...
Thank you all for your feedback. I agree a dongle would be a good thing. Could a generic soft device like Yubikey be used?
A generic key device will not do it. It requires the specific dongle you get from o-charts.
Alan, can please send us at o-charts a S-63 fingerprint of your flatpack install? We would like to have a closer look.
Hubert
@alannz42 those do not seem to be valid fingerprints or they got corrupted after compression. Could you please send us the files without changes and preserving the filenames as well? You can write to us at info[youknowwhat]o-charts.org
For the record. Both fingerprints generated from o-charts native and o-charts flatpak should be identical. This is valid for oeSENC/oeRNC and S63.
This has always been the case and continues to be the case in OpenCPN 5.10. Alannz42's case is a special one and we are trying to figure out what makes the fingerprints different.
@rgleason that entry in the docs should be removed.
Both fingerprints generated from o-charts native and o-charts flatpak should be identical.
Great to hear!
@rgleason that entry in the docs should be removed.
I'll take care of it
Both fingerprints generated from o-charts native and o-charts flatpak should be identical. Alannz42's case is a special one and we are trying to figure out what makes the fingerprints different.
Perhaps not that special. Attaching two fingerprints generated on a VirtualBox Bookworm vm, one on Flatpak and one on native 5.10 packages which differs.
We have already identified and reproduced Alannz42's issue. Sorry, we cannot provide any further details here. It is probably also related to the issue you are reproducing in a virtual environment. It is really strange that this has not been detected before, so maybe this is a bug in the new versions of oeSENC and S63. Working on it...
It is really strange that this has not been detected before [...]
At least I have been living with this since long, assuming it is the expected behaviour. Don't think I am the only one.
Both fingerprints generated from o-charts native and o-charts flatpak should be identical.
Let's take it from here: They should be identical, the fact that they ~don't~ differ is this bug.
Debian 12 - permits for S63 encrypted vector charts
Native openCPN accepts my userpermit/installpermit. Flatpak openCPN accepts my userpermit but not the installpermit.
OCPNsenc -k -e -u
accepts both keys as valid.
Why? - Same hardware - same operating system - I'd expect this to work.
Could be something to do with the flatpak permissions. I am lost here. I tried enabling all permissions in flatseal and openCPN would not run at all.
Any suggestions please?