guix-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]