[Pkg-privacy-maintainers] obfsproxy: Ship an AppArmor profile again

[Kevin P Dyer]

Thanks for the update.

I've created an issue to determine if we can remove the obfsproxy
dependency: https://github.com/kpdyer/fteproxy/issues/185.

-Kevin

On Mon, Dec 11, 2017 at 11:48 PM intrigeri <intrigeri at debian.org> wrote:

> Hi pkg-privacy-tools & fteproxy maintainers!
>
> Nicolas Braud-Santoni:
> > On Mon, Dec 11, 2017 at 07:21:50AM +0100, intrigeri wrote:
> >> I suggest first checking why we're still including obfsproxy:
> >> I suspect most of the reverse-dependency relationships might be
> >> obsolete nowadays (the last upstream version was released 3 years ago,
> >> and AFAIK obfs4proxy is the future).
>
> > Thanks, that's a great point:
> > - tor and ooniprobe suggest obfsproxy, and that should be dropped;
> >   ooniprobe should suggest obfs4proxy instead.
>
> Indeed since upstream commit e6035577f33b8d34a10117bf30bffda45719896a
> (first included in v2.1.0), ooniprobe's README.rst recommends
> installing obfs4proxy instead of obfsproxy.
>
> Nicolas, do you want to file bugs recommending these two changes?
>
> > - fteproxy hard-depends on obfsproxy, but uses it as a library so
> >   AppArmor confinement doesn't matter there.
>
> OK, so I've tagged #884043 wontfix.
>
> > Regarding fteproxy, it was listed at 0 recent uses (and 3 installs
> > in total).
>
> Dear fteproxy maintainers, if you ever decide that fteproxy should not
> be in the next Debian stable release, please let us know: this would
> allow us to also drop obfsproxy which is mostly dead upstream. In the
> meantime, let's keep obfsproxy in the archive as long as it's
> maintainable and fteproxy wants it :)
>
> Cheers,
> --
> intrigeri
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/attachments/20171213/4501e180/attachment.html>