From szczepan at nitrokey.com Wed Jul 4 16:50:54 2018 From: szczepan at nitrokey.com (Szczepan Zalega | Nitrokey) Date: Wed, 4 Jul 2018 16:50:54 +0200 Subject: [PATCH] Update script In-Reply-To: <5abd4031-fe2e-109b-c6af-4855b878bd44@nitrokey.com> References: <5abd4031-fe2e-109b-c6af-4855b878bd44@nitrokey.com> Message-ID: <5dea8dab-3f56-d00d-1092-f59e9cb212a1@nitrokey.com> On 07/04/2018 04:49 PM, Szczepan Zalega | Nitrokey wrote: > Attached are patches for the update by password script [1], which at the > moment fails with the update of devices with older firmwares. There are > a couple of other improvements too, like: > - killing scdaemon if update script cannot connect, > - better argument parsing, > - help screen, > - show device's string before and after update process, > > Patches are divided in such a way, that they could be merged selectively. > And here are other improvements: - missing package in tests readme, - add regnual build as well in Docker. -- Best regards, Szczepan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-install-requirement-for-.-tests.patch Type: text/x-patch Size: 711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Build-regnual-with-docker.patch Type: text/x-patch Size: 874 bytes Desc: not available URL: From szczepan at nitrokey.com Wed Jul 4 16:49:07 2018 From: szczepan at nitrokey.com (Szczepan Zalega | Nitrokey) Date: Wed, 4 Jul 2018 16:49:07 +0200 Subject: [PATCH] Update script Message-ID: <5abd4031-fe2e-109b-c6af-4855b878bd44@nitrokey.com> Hi! Attached are patches for the update by password script [1], which at the moment fails with the update of devices with older firmwares. There are a couple of other improvements too, like: - killing scdaemon if update script cannot connect, - better argument parsing, - help screen, - show device's string before and after update process, Patches are divided in such a way, that they could be merged selectively. [1] tool/upgrade_by_passwd.py -- Best regards, Szczepan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Handle-CLI-parsing-protect-from-mistakes-and-give-me.patch Type: text/x-patch Size: 4462 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Kill-scdaemon-on-connection-failure.patch Type: text/x-patch Size: 2413 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Rewrite-usb_strings.-Show-device-s-strings-before-an.patch Type: text/x-patch Size: 3452 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-typo.patch Type: text/x-patch Size: 884 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Catch-exception-when-no-KDF-data-is-found.patch Type: text/x-patch Size: 1537 bytes Desc: not available URL: From gniibe at fsij.org Fri Jul 13 09:41:18 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 13 Jul 2018 16:41:18 +0900 Subject: [PATCH] Update script In-Reply-To: <5abd4031-fe2e-109b-c6af-4855b878bd44@nitrokey.com> References: <5abd4031-fe2e-109b-c6af-4855b878bd44@nitrokey.com> Message-ID: <877elzoa5d.fsf@iwagami.gniibe.org> Hello, Thanks for your patches. I applied the first two, which require no discussion. For others, let me have more time. Firstly, for Python programming, I think that all import should be done earlier (not only in some function or in some if clause). That's because if import fails in the deep call chain, sometime, it is a disaster, where user can do no recovery. Secondly, I don't agree the way like 0004-Kill-scdaemon-on-connection-failure.patch. Let user invoke the command. For 0005-Handle-CLI-parsing-protect-from-mistakes-and-give-me.patch, I partially agree it will be useful, but I wonder if your intended "user" uses GUI or not. -- From szczepan at nitrokey.com Fri Jul 13 13:54:48 2018 From: szczepan at nitrokey.com (Szczepan Zalega | Nitrokey) Date: Fri, 13 Jul 2018 13:54:48 +0200 Subject: [PATCH] Update script In-Reply-To: <877elzoa5d.fsf@iwagami.gniibe.org> References: <5abd4031-fe2e-109b-c6af-4855b878bd44@nitrokey.com> <877elzoa5d.fsf@iwagami.gniibe.org> Message-ID: <916bea6f-69a8-3b58-890b-1ddaf15d8c9f@nitrokey.com> On 07/13/2018 09:41 AM, NIIBE Yutaka wrote: > I applied the first two, which require no discussion. For others, let > me have more time. > Hi! Thank you for the review! As a general comment - I tried to make it as easy to use as possible, so users could be up to date with no effort or frustration, regardless of their overall PC experience level. > Firstly, for Python programming, I think that all import should be done > earlier (not only in some function or in some if clause). That's > because if import fails in the deep call chain, sometime, it is a > disaster, where user can do no recovery. > I agree and will keep that in mind. Besides `requirements.txt` we could keep `import` in try/catch block and print further installation instructions to user. > Secondly, I don't agree the way like > 0004-Kill-scdaemon-on-connection-failure.patch. Let user invoke the > command. > Scdaemon owning a device is the most frequent cause of the script update failure on Ubuntu I am aware of (and perhaps other distros, where scdaemon/pcscd are used), hence the solution. It is called only on connection failure and is easily recoverable as well (it starts on request from GnuPG), so it should be pretty harmless. Alternatively the whole command could be printed to the console with the proper further guide. > For 0005-Handle-CLI-parsing-protect-from-mistakes-and-give-me.patch, I > partially agree it will be useful, but I wonder if your intended "user" > uses GUI or not. > To be honest I was myself frequently opening the update script to see, whenever I supply the binaries in the correct order and the improvements here are making this checks for me. Argparse module is in Python since 3.2 (and in 2.7), so there are no further installation actions required. I do not entirely get the GUI reference - could you elaborate? If you feel it GUI-like in the sense of guiding the user, then I think this is a good experience :-) Regarding making a separate update GUI application, I have plans for it (for further future). What is your opinion on moving the Python tools to 3.x? As far as I remember 2.7 will be stopped being supported this year. -- Best regards, Szczepan From gniibe at fsij.org Tue Jul 17 09:06:26 2018 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 17 Jul 2018 16:06:26 +0900 Subject: [PATCH] Update script In-Reply-To: <916bea6f-69a8-3b58-890b-1ddaf15d8c9f@nitrokey.com> References: <5abd4031-fe2e-109b-c6af-4855b878bd44@nitrokey.com> <877elzoa5d.fsf@iwagami.gniibe.org> <916bea6f-69a8-3b58-890b-1ddaf15d8c9f@nitrokey.com> Message-ID: <87r2k25ojx.fsf@fsij.org> Szczepan Zalega | Nitrokey wrote: > Thank you for the review! As a general comment - I tried to make it as > easy to use as possible, so users could be up to date with no effort or > frustration, regardless of their overall PC experience level. Perhaps, those scripts are not ready for that. The situation is: I put a script in the repo, so that it's useful, it's a kind of... to show how it should work technically. If we will prepare such a tool to user, I think that it should be installed in the system. At least, we should name a tool and/or define relevant methods to use that. Let us consider about that. Well, I think that providing a command named "gnuk-tool" would be good, to have sub-commands which is implemented by each script. How do you think? -- From szczepan at nitrokey.com Tue Jul 17 16:55:09 2018 From: szczepan at nitrokey.com (Szczepan Zalega | Nitrokey) Date: Tue, 17 Jul 2018 16:55:09 +0200 Subject: [PATCH] Update script In-Reply-To: <87r2k25ojx.fsf@fsij.org> References: <5abd4031-fe2e-109b-c6af-4855b878bd44@nitrokey.com> <877elzoa5d.fsf@iwagami.gniibe.org> <916bea6f-69a8-3b58-890b-1ddaf15d8c9f@nitrokey.com> <87r2k25ojx.fsf@fsij.org> Message-ID: <763f7f6c-bb55-5b54-0375-ae39ee83d022@nitrokey.com> On 07/17/2018 09:06 AM, NIIBE Yutaka wrote: > Perhaps, those scripts are not ready for that. The situation is: I put > a script in the repo, so that it's useful, it's a kind of... to show how > it should work technically. > I see, like a tech-demo. > If we will prepare such a tool to user, I think that it should be > installed in the system. At least, we should name a tool and/or define > relevant methods to use that. > Yes. Such tool could be distributed and installed via Python's PIP. Having all in Python would make it portable. > Let us consider about that. Well, I think that providing a command > named "gnuk-tool" would be good, to have sub-commands which is > implemented by each script. > So it would be something like: '$ gnuk-tool update regnual.bin gnuk.bin' I think this is a good idea. It should simplify device's management. Assuming existing implementation could be adjusted, alternatively to starting work directly on the final tool, we could incrementally work towards the target with two stages: first to update each script separately with a better UI, and later to compose a single tool from this scripts' set to finally do a proper packagement. Are there any other features you would see usable for the final tool, besides existing scripts? -- Best regards, Szczepan