On Tue, Sep 08, 2020 at 05:54:42PM +0200, Alec Leamas wrote: > Hi Tobias, > > Thanks for taking some time for this! > > On 08/09/2020 16:29, Tobias Frost wrote: > > > a short review: > > > > * New upstream release including plugin downloader. Closes: 948702 > > > > It is a privacy violation to download stuff. Do you inform your user about it? > > > Not really. Do you think a patch is motivated? If so, for each and every > plugin, or just for the first one? I'm not sure how plugins are installed. If there is an UI, the warning could be presented in that gui. > > > Are the downloads somehow validated that it won't execute malicious / (MITM) > > modified code? > > > I'm fairly active upstream where these plugins are created. They all > live on github, and the sources are available. > > The actual list of downloadable plugins (the plugin catalog) is kept > under tight control upstream. I meant with Man in the Middle: There would be many possiblities for attacks… If they are not protected by e.g a checksum, Malice one could replace them, either in the repo or in transit. There is no gurantee that binaries match the sources, as well, if not build in trusted enviorments or somehow signed. … "tight control upstream" somehow sounds that you control what plugins can be installed. Just to make sure that we cover all those freedoms we care about: I can have my own plugin installed, right? > > > (It would be better if plugins of relevance would be packaged.) > > > It's just not feasible. There are some 20 plugins, and just the > administrative work is IMHO prohibitive. Also, the user experience is > built around a workflow which does not fly using packaged plugins. OK, maybe, I'm not a user, so I can't tell. However, you don't likely need _all_ plugins packaged… On the other side, it feels like reinventing the wheel… Packaged plugins have advantages too, because the packaging system can be your friend: eg. the dependency handling, security, support when your package is part of a stable release (where you e.g can't update your package at will; so you possibly need to maintain the plugins for several years until the stable release becomes no longer supported… (I think you mentioned that problem in #948702#20 with gtk2/gtk3… how do you plan to solve that when future Debian unstable has a higher gtk stack than a stable one; just an extreme example for the dependency hell that might loom here, even if this'd be worst case…) IOW, I think you will just upstream the required work that the packaging system would take away from you… (Beside that Debian release mechanics are working differnetly here, problably getting in your way sooner or later: testing/ unstable is quite a moving target… Debian users also expect that the software is _stable_ in the sense of _feature stable_, so e.g upgrading plugins in a stable release will cause surprises to the causal Debian user) (Also, likely, the plugins would be similar enough so that the overhead is limited, once one package is nice enough as a master copy for the others ;-)) How are you planning to support all the architecures Debian supports? But as indicated earlier, I'm OK with that (other Debian member might not); Its just you need to be aware of the downsides as well… OpenCPN#2033 has some very valid points. > > > Consistency: in other changelog entries you write a #bugnumber, here only > > bugnumer… > > > > * Add two plugin compatiblity patches (#1997). > > > The lower numbers are upstream bugs. Sort of obvious, but only for me... > Should the notation opencpn#1997 work? Nah, I meant the fist line and second line of the d/changelog. d/changelog is actually only to record changes for the Debian packaging itself, not for upstream changes. (IOW, dont record stuff in d/changelog that have no changes in the debian directory) > > > Spelling error: > > W: opencpn-plugins: spelling-error-in-changelog compatiblity compatibility > > > Agreed, will fix > > > - d/copyright has some todos: > > > "blushes" Will fix. > > > - compat-level is still at 12. > > > Actually on purpose to make ubuntu backports somewhat easier. I could > certainly upgrade if you feel that this is the correct decision. OK, valid point for me. > Sending this reply now so I hopefully can get some more input before > doing real work. > > Again: thanks for reviewing! Welcome, and sorry for being too Debianite ;-) You plugin approach is not how we usually do things here… > > Cheers! > --alec
Attachment:
signature.asc
Description: PGP signature