Bug#829478: shadowsocks-libev: modifies conffiles (policy 10.7.3): /etc/shadowsocks-libev/config.json

2016-07-05 Thread Andreas Beckmann 
On 2016-07-05 22:15, Roger Shimizu wrote:
> So I need to remove the config entry in .install file, and move it to
> .doc, so it will be installed to /usr/share/doc/
> just let the postinst script to generate a new config under /etc should be 
> fine.

Put the template into /usr/share/, not /usr/share/doc, since
/usr/share/doc may be excluded from installation.
Policy 12.3: "Packages must not require the existence of any files in
/usr/share/doc/ in order to function."

Andreas

Bug#829478: shadowsocks-libev: modifies conffiles (policy 10.7.3): /etc/shadowsocks-libev/config.json

2016-07-05 Thread Roger Shimizu 
Dear Andreas,

Thanks for helping on this package!

On Mon, Jul 4, 2016 at 11:35 AM, Andreas Beckmann  wrote:
> On 2016-07-04 09:31, Roger Shimizu wrote:
>> The fix may be one of the following:
>> - move the config from /etc/ to somewhere else, such as /var/cache
>> - use debconf to get the password from user when install, as Andreas
>> said in previous email
>
> Ship a config file template in /usr/share/$PACKAGE/...
> The file (whereever you place it) created by the maintainer scripts is
> *not* shipped by the package but only managed by the maintainer scripts.
>
> Maybe look into using ucf to manage it.

I find the docs:
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles
it mentioned one solution is: "Create a file generated by the
maintainer scripts under the /etc directory"

So I need to remove the config entry in .install file, and move it to
.doc, so it will be installed to /usr/share/doc/
just let the postinst script to generate a new config under /etc should be fine.

Cheers,
-- 
Roger Shimizu, GMT +2 Cape Town (in DebConf16)
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#829478: shadowsocks-libev: modifies conffiles (policy 10.7.3): /etc/shadowsocks-libev/config.json

2016-07-04 Thread Andreas Beckmann 
On 2016-07-04 09:31, Roger Shimizu wrote:
> The fix may be one of the following:
> - move the config from /etc/ to somewhere else, such as /var/cache
> - use debconf to get the password from user when install, as Andreas
> said in previous email

Ship a config file template in /usr/share/$PACKAGE/...
The file (whereever you place it) created by the maintainer scripts is
*not* shipped by the package but only managed by the maintainer scripts.

Maybe look into using ucf to manage it.


Andreas

Bug#829478: shadowsocks-libev: modifies conffiles (policy 10.7.3): /etc/shadowsocks-libev/config.json

2016-07-04 Thread Roger Shimizu 
Dear Boyuan,

Thanks for your info!

Please don't reply to , which is for reporting new bug.

On Mon, Jul 4, 2016 at 9:16 AM, YANG Boyuan <073p...@gmail.com> wrote:
> Hi all,
>
> It's pretty clear that this problem was introduced in RFS procedure
> [0]. Seems that it is not a good solution and should be reverted.
>
> The mentor in RFS procedure was worried about *fixed* password in
> conffile [1], and the solution was to use apg in postinst script [0].
> I would state that the originally proposed problem actually does not
> exist.
>
> First of all, the default shipped conffile is a stub [2] and will not
> work if you don't modify it. The server will listen to 127.0.0.1:8388
> and not  accessible from external network, so no security vulanability
> will take place. We should expect users to change the fixed password
> when doing necessary configurations.

You cannot assume the package always installs on the box behind the NAT gateway.

> But if the fixed password *is* a problem, a better solution may be not
> to ship configuration json file by default. One (or more) example
> configuration file(s) may be shipped as a demonstration.
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825532#57
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825532#43
> [2] https://github.com/rogers0/shadowsocks-libev/blob/pkg7/debian/config.json

The fix may be one of the following:
- move the config from /etc/ to somewhere else, such as /var/cache
- use debconf to get the password from user when install, as Andreas
said in previous email

I'll investigate more on this issue later.

Cheers,
-- 
Roger Shimizu, GMT +2 Cape Town (in DebConf16)
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#829478: shadowsocks-libev: modifies conffiles (policy 10.7.3): /etc/shadowsocks-libev/config.json

2016-07-04 Thread YANG Boyuan 
Hi all,

It's pretty clear that this problem was introduced in RFS procedure
[0]. Seems that it is not a good solution and should be reverted.

The mentor in RFS procedure was worried about *fixed* password in
conffile [1], and the solution was to use apg in postinst script [0].
I would state that the originally proposed problem actually does not
exist.

First of all, the default shipped conffile is a stub [2] and will not
work if you don't modify it. The server will listen to 127.0.0.1:8388
and not  accessible from external network, so no security vulanability
will take place. We should expect users to change the fixed password
when doing necessary configurations.

But if the fixed password *is* a problem, a better solution may be not
to ship configuration json file by default. One (or more) example
configuration file(s) may be shipped as a demonstration.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825532#57
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825532#43
[2] https://github.com/rogers0/shadowsocks-libev/blob/pkg7/debian/config.json

--
Regards,
Boyuan Yang


2016-07-04 0:43 GMT+08:00 Andreas Beckmann :
> Package: shadowsocks-libev
> Version: 2.4.7+20160630+ds-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package modifies conffiles.
> This is forbidden by the policy, see
> https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
>
> 10.7.3: "[...] The easy way to achieve this behavior is to make the
> configuration file a conffile. [...] This implies that the default
> version will be part of the package distribution, and must not be
> modified by the maintainer scripts during installation (or at any
> other time)."
>
> Note that once a package ships a modified version of that conffile,
> dpkg will prompt the user for an action how to handle the upgrade of
> this modified conffile (that was not modified by the user).
>
> Further in 10.7.3: "[...] must not ask unnecessary questions
> (particularly during upgrades) [...]"
>
> If a configuration file is customized by a maintainer script after
> having asked some debconf questions, it may not be marked as a
> conffile. Instead a template could be installed in /usr/share and used
> by the postinst script to fill in the custom values and create (or
> update) the configuration file (preserving any user modifications!).
> This file must be removed during postrm purge.
> ucf(1) may help with these tasks.
> See also https://wiki.debian.org/DpkgConffileHandling
>
> In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
> followups it has been agreed that these bugs are to be filed with
> severity serious.
>
> debsums reports modification of the following files,
> from the attached log (scroll to the bottom...):
>
>   /etc/shadowsocks-libev/config.json
>
>
> cheers,
>
> Andreas

Bug#829478: shadowsocks-libev: modifies conffiles (policy 10.7.3): /etc/shadowsocks-libev/config.json

2016-07-03 Thread Andreas Beckmann 
Package: shadowsocks-libev
Version: 2.4.7+20160630+ds-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies conffiles.
This is forbidden by the policy, see
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files

10.7.3: "[...] The easy way to achieve this behavior is to make the
configuration file a conffile. [...] This implies that the default
version will be part of the package distribution, and must not be
modified by the maintainer scripts during installation (or at any
other time)."

Note that once a package ships a modified version of that conffile,
dpkg will prompt the user for an action how to handle the upgrade of
this modified conffile (that was not modified by the user).

Further in 10.7.3: "[...] must not ask unnecessary questions
(particularly during upgrades) [...]"

If a configuration file is customized by a maintainer script after
having asked some debconf questions, it may not be marked as a
conffile. Instead a template could be installed in /usr/share and used
by the postinst script to fill in the custom values and create (or
update) the configuration file (preserving any user modifications!).
This file must be removed during postrm purge.
ucf(1) may help with these tasks.
See also https://wiki.debian.org/DpkgConffileHandling

In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

debsums reports modification of the following files,
from the attached log (scroll to the bottom...):

  /etc/shadowsocks-libev/config.json


cheers,

Andreas


shadowsocks-libev_2.4.7+20160630+ds-1.log.gz
Description: application/gzip