unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* policy for packaging insecure apps
@ 2024-04-10  8:51 Attila Lendvai
  2024-04-19  2:16 ` Maxim Cournoyer
  0 siblings, 1 reply; 2+ messages in thread
From: Attila Lendvai @ 2024-04-10  8:51 UTC (permalink / raw)
  To: guix-devel

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.

a detailed discussion is available at:

https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/issues/138

the fact that its name suggests that it is *the* standard gnome clipboard app makes the situation that much worse.


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.

 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?

 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?

 4) is this the responsibility of a project like guix to address
    situations like this?

 5) do you know another forum where this dispute should be brought up
    instead of guix-devel?

i'm looking forward to your thoughts, and/or any pointers or patches to the documentation that i should read.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
The price of liberty is eternal vigilance.



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: policy for packaging insecure apps
  2024-04-10  8:51 policy for packaging insecure apps Attila Lendvai
@ 2024-04-19  2:16 ` Maxim Cournoyer
  0 siblings, 0 replies; 2+ messages in thread
From: Maxim Cournoyer @ 2024-04-19  2:16 UTC (permalink / raw)
  To: Attila Lendvai; +Cc: guix-devel

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-04-19  2:17 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-10  8:51 policy for packaging insecure apps Attila Lendvai
2024-04-19  2:16 ` Maxim Cournoyer

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).