[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: policy for packaging insecure apps
From: |
Maxim Cournoyer |
Subject: |
Re: policy for packaging insecure apps |
Date: |
Thu, 18 Apr 2024 22:16:51 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi Attila,
Attila Lendvai <attila@lendvai.name> writes:
> the context:
> ------------
>
> there's an app currently packaged in guix, namely
> gnome-shell-extension-clipboard-indicator, that has a rather questionable
> practice: by default it saves the clipboard history (passwords included) in
> clear text, and the preferences for it is called something obscure. its
> author actively defends this situation for several years now, rejecting
> patches and bug reports.
Are there no forks yet?
[...]
> my question:
> ------------
>
> how shall we deal with a situation like this?
>
> 1) shall i create a guix patch that makes the necessary changes in
> this app, and submit it to guix? this would be a non-trivial, and
> a rather hidden divergence from upstream, potentially leading to
> confusion.
Perhaps enough people are interested in getting this in order to have
created a fork already? We could use it.
> 2) is there a way to attach a warning message to a package to explain
> such situations to anyone who installs them? should there be a
> feature like that? should there be a need for a --force switch, or
> an interactive y/n, to force installing such apps?
For now, I think a simple mention of the issue in the description could
be enough.
> 3) is there a point where packages refusing to address security
> issues should be unpackaged? and also added to a blacklist until the
> security issue is resolved? where is that point? would this one
> qualify?
Is the issue is severe enough (I don't think it is the case here -- it
seems a note to its description would be sufficient -- but I haven't
looked closely into it), I think the package could be dropped, discussed
as a patch.
> 4) is this the responsibility of a project like guix to address
> situations like this?
When the security risks introduced are severe, I'd say so (by excluding
such package from our collection) -- but it would need to be something
truly problematic.
--
Thanks,
Maxim