Bug#1002997: podman: Please provide a default /etc/containers/storage.conf

[Giuseppe Scrivano]

Valentin Rothberg  writes:

> Hi folks,
>
> Thanks for pulling me in.
>
> On Sun, Jan 9, 2022 at 11:15 PM Reinhard Tartler  wrote:
>
>  Control: reassign -1 storage-common
>  Control: affects -1 podman
>
>  Hi Philip,
>
>  Thank you for your bug report. I'll defer to our overlay expert, Giuseppe.
>
>  The Debian equivalent to Fedora's package 'containers-common' has the same 
> name in debian, and does ship a 'storage.conf' file in 
> /usr/share/containers/storage.conf. This is so that the local
>  administrator can copy it to /etc/containers/storage.conf and do local 
> modifications. The Debian package copies the storage.conf from the upstream 
> source verbatim. As you can see at
>  
> https://github.com/containers/storage/blob/375f77c66685b14fc580daad2dc6df607fb86dee/storage.conf#L95,
>  the mount option 'metacopy=on' is missing even upstream.
>
>  I am not sure why the Fedora package decided to patch the configuration file 
> -- I couldn't find a comment in the .src.rpm that you linked. Also, looking 
> at the kernel documentation you provided, it
>  seems your concerns re: security are justified, and the option seems to have 
> significant security implications:
>
>  Do not use metacopy=on with untrusted upper/lower directories. Otherwise it 
> is possible that an attacker can create a handcrafted file with appropriate 
> REDIRECT and METACOPY xattrs, and
>  gain access to file on lower pointed by REDIRECT. This should not be 
> possible on local system as setting “trusted.” xattrs will require 
> CAP_SYS_ADMIN. But it should be possible for untrusted
>  layers like from a pen drive.
>
>  I'm not sure whether enabling it by default is a good idea. I need to think 
> more about this.
>
> @Giuseppe Scrivano what do you think?

please keep in mind that unprivileged overlay mounts cannot use
metacopy.  You still need root access on the host (CAP_SYS_ADMIN in
the initial user namespace) in order to use metacopy=on.

While it is safe to pull random images from the network and expect they
cannot exploit the system to gain access to files outside the image
itself, there is no guarantee when you are using a handcrafted storage
repository as you seem to imply with the pen drive example.
There are so many things that can be abused that metacopy=on is the last
I'd worry about :-)  For such cases, I suggest to use rootless, and rely
on the kernel to limit what the unpriviled user can do.

Regards,
Giuseppe



>  I'd also appreciate hearing additional opinions on this, and have copied 
> some friends from podman upstream. Do you happen to know what's the 
> background / thinking in Fedora with enabling the
>  option metacopy=on?
>
>  Happy New Year!
>
>  -rt
>
>  On Sun, Jan 2, 2022 at 9:51 AM Philip  wrote:
>
>  Package: podman
>  Version: 3.0.1+dfsg1-3+b2
>  Severity: wishlist
>
>  Dear Maintainer,
>
>  I had some problems running the dockerized version of the Unifi controller 
> jacobalberty/unifi-docker
>  with podman on Debian.
>  On a Fedora system, starting the container only takes a few seconds.
>  On a Debian system, it can take about 5 minutes.
>
>  The reason is that on the Fedora system the mount-option metacopy=on
>  (see  [1] for this mount option) is set for the container overlayfs via a 
> default /etc/containers/storage.conf.
>  That makes quite the difference for this specific image because it does a
>  `chown unifi:unifi /usr/lib/unifi` during startup.
>  chown-ing these 6k files is fast with metacopy=on (on Fedora).
>  Without the option (on Debian), I think the files will be copied instead of 
> only their metadata, making it rather slow.
>
>  So the solution for me was to copy /etc/containers/storage.conf from a
>  Fedora system. If anyone has a similar problem, the file can be extracted 
> from the
>  src rpm of the containers-common package which can be downloaded at [2].
>
>  IMO it would be useful if Debian would also include a default
>  /etc/containers/storage.conf.
>  Thanks for considering this!
>  However I'm not sure if metacopy=on is a good idea from a security
>  perspective.
>
>  Best
>  Philip
>
>  -- System Information:
>  Debian Release: 11.2
>APT prefers stable-updates
>APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
>  Architecture: amd64 (x86_64)
>
>  Kernel: Linux 5.10.0-10-amd64 (SMP w/2 CPU threads)
>  Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
>  Shell: /bin/sh linked to /usr/bin/dash
>  Init: systemd (via /run/systemd/system)
>  LSM: AppArmor: enabled
>
>  Versions of packages podman depends on:
>  ii  conmon   2.0.25+ds1-1.1
>  ii  containerne

Bug#797057: [PATCH] [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Giuseppe Scrivano]

Tim Ruehsen  writes:

> wgnutls_write is called without timeout. So, what can we do here ?
>
> But maybe we don't have to check for GNUTLS_E_REHANDSHAKE at this point at 
> all. Regarding 
> http://www.gnutls.org/manual/html_node/Re_002dauthentication.html, only 
> gnutls_record_recv() returns GNUTLS_E_REHANDSHAKE.
>
> If you don't mind, I'll remove the rehandshake code from wgnutls_write().

yes, if it cannot return that error code, please drop the code that
checks for it.

Regards,
Giuseppe

Bug#797057: [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Giuseppe Scrivano]

Follow-up Comment #3, bug #46061 (project wget):

Good analysis Tim!  I have attacheda patch that solves the problem for me

(file #35002)
___

Additional Item Attachment:

File name: 0001-gnutls-honor-error-GNUTLS_E_REHANDSHAKE.patch Size:4 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#797057: [PATCH] [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Giuseppe Scrivano]

Tim Ruehsen  writes:

> Please review / test this patch.

we basically wrote the same patch :)

It looks fine to me, just please add a space in the function calls:

"_do_handshake(" -> "_do_handshake ("

and feel free to push it.

Regards,
Giuseppe

Bug#797057: [PATCH] [bug #46061] wget https://contributors.debian.org fails with "No data received."

[Giuseppe Scrivano]

Tim Ruehsen  writes:

> Please review / test this patch.
>
> BTW, I am not sure if contributors.debian.org is configured correctly.
> The rehandshake occurs right after the HTTP request and it has a pretty heavy 
>  
> impact on download duration.
>
> Regards, Tim
>
> On Sunday 27 September 2015 20:03:54 Tim Ruehsen wrote:
>> Follow-up Comment #2, bug #46061 (project wget):
>> 
>> Wget is not reacting on GNUTLS_E_REHANDSHAKE. Should be straight forward...
>> 
>> 
>> ___
>> 
>> Reply to this item at:
>> 
>>   
>> 
>> ___
>>   Nachricht gesendet von/durch Savannah
>>   http://savannah.gnu.org/
>
> From cbec5b0c780f9d1fc343fabf22e8ee7c7cb3222d Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Tim=20R=C3=BChsen?= 
> Date: Mon, 28 Sep 2015 12:00:33 +0200
> Subject: [PATCH] Handle TLS rehandshakes in GnuTLS code
>
> * src/gnutls.c: New static function _do_handshake()
> * src/gnutls.c (wgnutls_read_timeout): Handle rehandshake
> * src/gnutls.c (wgnutls_write): Handle rehandshake
> * src/gnutls.c (ssl_connect_wget): Move handshake code into _do_handshake()
>
> Fixes #46061
> ---
>  src/gnutls.c | 179 
> ++-
>  1 file changed, 102 insertions(+), 77 deletions(-)
>
> diff --git a/src/gnutls.c b/src/gnutls.c
> index a38301a..2f53592 100644
> --- a/src/gnutls.c
> +++ b/src/gnutls.c
> @@ -57,6 +57,9 @@ as that of the covered work.  */
>  #include "host.h"
>  
>  static int
> +_do_handshake(gnutls_session_t session, int fd, double timeout);
> +
> +static int
>  key_type_to_gnutls_type (enum keyfile_type type)
>  {
>switch (type)
> @@ -277,6 +280,12 @@ wgnutls_read_timeout (int fd, char *buf, int bufsize, 
> void *arg, double timeout)
>  {
>ret = gnutls_record_recv (ctx->session, buf, bufsize);
>timed_out = timeout && ptimer_measure (timer) >= timeout;
> +  if (!timed_out && ret == GNUTLS_E_REHANDSHAKE)
> +{
> +  DEBUGP (("GnuTLS: *** REHANDSHAKE while reading\n"));
> +  if ((ret = _do_handshake(ctx->session, fd, timeout)) == 0)
> +ret = GNUTLS_E_AGAIN; /* restart reading */
> +}
>  }
>  }
>while (ret == GNUTLS_E_INTERRUPTED || (ret == GNUTLS_E_AGAIN && 
> !timed_out));
> @@ -332,7 +341,15 @@ wgnutls_write (int fd _GL_UNUSED, char *buf, int 
> bufsize, void *arg)
>int ret;
>struct wgnutls_transport_context *ctx = arg;
>do
> -ret = gnutls_record_send (ctx->session, buf, bufsize);
> +{
> +  ret = gnutls_record_send (ctx->session, buf, bufsize);
> +  if (ret == GNUTLS_E_REHANDSHAKE)
> +{
> +  DEBUGP (("GnuTLS: *** REHANDSHAKE while writing\n"));
> +  if ((ret = _do_handshake(ctx->session, fd, 0)) == 0)

one thing: timeout here should be the remaining time instead of 0?

Regards,
Giuseppe

Bug#281201: [bug #45790] wget prints it's progress even when background

[Giuseppe Scrivano]

Darshit Shah dar...@gmail.com writes:

 This affects an invokation using the shell's background operator () too.

 E.g.: wget 
 http://cdimage.debian.org/debian-cd/current/multi-arch/iso-cd/debian-8.1.0-amd64-i386-netinst.iso
 
 will cause the logging output and progress bar to be displayed on the
 terminal as explained in the bug report.

 However, I am not willing to fix that behaviour. A huge number of
 people copy URLs and paste them in their terminals for Wget to
 download without double-quoting them. A large number of these URLs
 have the  character which causes the shell to background the
 process. They tend to realise that something went wrong when the
 screen is garbled by a background process spewing messages to stdout
 and stderr. If this behaviour is changed, many people won't realise
 their error and un-necessarily invoke multiple instances of
 backgrounded Wget processes, eventually coming back here with new bug
 reports.

 The bahviour has remained so for a long time and I'm inclined to
 retain the status quo.

I agree with you here, the behavior should not be changed.  It would be
a bug if wget stops reporting errors when resumed.

Regards,
Giuseppe

Bug#784348: [bug #45037] wget -O foo ftp://ftp.funet.fi/pub/Linux/mirrors/debian/README deletes README symlink

[Giuseppe Scrivano]

Follow-up Comment #1, bug #45037 (project wget):

slightly related bug..

$ ln -s /etc/passwd README

$ wget  -O README http://foo.bar
README: Permission denied


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?45037

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#144076: [Bug-wget] [PATCH] wget -nv doesn't show enough errors

[Giuseppe Scrivano]

Tim Ruehsen tim.rueh...@gmx.de writes:

 On Friday 09 January 2015 14:51:00 Darshit Shah wrote:
 I don't see any issue with this patch. No-verbose does need to print a
 little bit more information I think.
 
 However, @giuseppe, @Tim, do you'll see any issues with scripts
 parsing Wget's --nv output if we apply this patch?

 For me, it is fine. You never know about how good or bad scripts are grepping 
 Wget's output. I would say, if this patch breaks a script, the script should 
 be fixed.

I am fine with it too, as anyway scripts should not depend from the wget output.

Giuseppe


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701032: [bug #41003] wget tries to reuse connection despite http/1.0 and no connection: keep-alive

[Giuseppe Scrivano]

Follow-up Comment #2, bug #41003 (project wget):

by inspecting the code, I see that wget doesn't check for the version of the
HTTP protocol and it should assume no keep-alive connection by default when
HTTP/1.0 is used.

Darshit, if you specify --debug, do you get the Registered socket %d for
persistent reuse.\n message?

I was quickly testing with netcat as:

$ printf HTTP/1.0 200 OK\r\nContent-Length: 0\r\n\r\n | nc -l -p 8080

$ LANG=C ./wget -d -O /dev/null http://localhost:8080/ 21  | grep
Registered
Registered socket 4 for persistent reuse.



___

Reply to this item at:

  http://savannah.gnu.org/bugs/?41003

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#699337: [bug #39780] Wget omits Host header for CONNECT (RFC 2616)

[Giuseppe Scrivano]

Update of bug #39780 (project wget):

  Status:None = Fixed  
 Open/Closed:Open = Closed 
 Planned Release:None = 1.15   

___

Follow-up Comment #1:

the patch is applied upstream now.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?39780

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684189: [bug #37055] Please add DELETE method

[Giuseppe Scrivano]

Update of bug #37055 (project wget):

  Status:None = Fixed  
 Assigned to:None = gscrivano  
 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

wget upstream supports --method that allows to specify which HTTP method
should be used.  It will be part of the next wget version.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?37055

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#697081: [bug #38015] ca_ES.UTF-8 changes option -nv: inaccurate catalan translation

[Giuseppe Scrivano]

Update of bug #38015 (project wget):

 Assigned to:None = gscrivano  
 Open/Closed:Open = Closed 
  Regression: Yes = No 
  Patch Included: Yes = No 


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?38015

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#672131: File name too long

[Giuseppe Scrivano]

Update of bug #21714 (project wget):

  Status:Needs Discussion = Fixed  
 Assigned to:None = gscrivano  
 Open/Closed:Open = Closed 

___

Follow-up Comment #51:

Applied as commit: 67e6027ea130d06aeff365adfbc83f34d019b968

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?21714

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#672131: [bug #21714] File name too long

[Giuseppe Scrivano]

Update of bug #21714 (project wget):

 Assigned to:  alotau = None   

___

Follow-up Comment #50:

I am going to take a look at the patch in the next few days.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?21714

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#247985: [bug #27303] Enable users to download bodies from non-200 HTTP responses.

[Giuseppe Scrivano]

Follow-up Comment #4, bug #27303 (project wget):

this feature will be part of the next wget release.  It is already in the
development version.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?27303

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#247985: [bug #27303] Enable users to download bodies from non-200 HTTP responses.

[Giuseppe Scrivano]

Update of bug #27303 (project wget):

 Assigned to:None = gscrivano  
 Open/Closed:Open = Closed 
 Planned Release:1.15 = 1.14   


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?27303

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#646983: [Bug-wget] [PATCH] enable client certificates with wget when linked against GnuTLS

[Giuseppe Scrivano]

Daniel Kahn Gillmor d...@fifthhorseman.net writes:

 tags 646983 + patch
 forwarded 646983 
 https://lists.gnu.org/archive/html/bug-wget/2011-10/msg00051.html
 thanks

 It looks to me like the GnuTLS bindings for wget don't do anything
 with client-side certificate credentials.  I suspect this is the cause
 of the bug Clint ran into.

 In debian, wget transitioned from openssl to gnutls between 1.12 and
 1.13, which would explain why Clint's Error in the push function
 happened last Hallowe'en.

 The attached diff enables client-certficates when wget is linked against
 GnuTLS.

Thanks, I have done some trivial changes to the indentation, added a
ChangeLog entry and committed it!

Giuseppe



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#402001: [bug #33823] 'wget -c -N' ignores timestamps

[Giuseppe Scrivano]

Update of bug #33823 (project wget):

 Open/Closed:Open = Closed 


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33823

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#624675: [bug #33831] wget --backup-converted does not work

[Giuseppe Scrivano]

Update of bug #33831 (project wget):

  Status:Cannot Reproduce = Fixed  
 Open/Closed:Open = Closed 

___

Follow-up Comment #2:

it was a problem in the documentation that is fixed in the development
version.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33831

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#612450: [bug #33835] don't limit DNS results to 3 (src/host.c)

[Giuseppe Scrivano]

Update of bug #33835 (project wget):

  Status:None = Fixed  
 Assigned to:None = gscrivano  
 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

I have introduced a configuration value showalldnsentries.  When it is set
to on then all the DNS entries are printed.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33835

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#141323: [bug #33839] wget -nv outputs non-error output to stderr

[Giuseppe Scrivano]

Update of bug #33839 (project wget):

  Status:None = Inspected  
 Assigned to:None = gscrivano  

___

Follow-up Comment #1:

POSIX defines stderr as: standard error (for writing diagnostic output). 
That one is a diagnostic message so it is not a problem to use stderr for it.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33839

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#402001: [bug #33823] 'wget -c -N' ignores timestamps

[Giuseppe Scrivano]

Update of bug #33823 (project wget):

  Status:None = Fixed  
 Assigned to:None = gscrivano  

___

Follow-up Comment #1:

fixed in the development version.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33823

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#565942: [bug #33827] wget: -A/-R vs. -O

[Giuseppe Scrivano]

Update of bug #33827 (project wget):

  Status:None = Fixed  
 Assigned to:None = gscrivano  
 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

thanks to have reported it.  The fix is in the source repository and will be
included in the next release.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33827

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#624675: [bug #33831] wget --backup-converted does not work

[Giuseppe Scrivano]

Update of bug #33831 (project wget):

  Status:None = Cannot Reproduce   
 Assigned to:None = gscrivano  

___

Follow-up Comment #1:

I couldn't reproduce the problem, if I launch the command I get backup-ed
files and having a bunch of .orig and .html files.


Can you please give more information?  Why is not it following the
documentation?


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33831

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#626438: [bug #33834] --adjust-extension renames .htm files

[Giuseppe Scrivano]

Update of bug #33834 (project wget):

  Status:None = Fixed  
 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

already done in the development version.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33834

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#500395: [bug #33825] 'wget -nc' race condition

[Giuseppe Scrivano]

Update of bug #33825 (project wget):

  Status:None = Wont Fix   
 Assigned to:None = gscrivano  

___

Follow-up Comment #1:

wget is not designed in a way that multiple instances can write concurrently
to the same set of files.  In these cases, the behaviour is undefined.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33825

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#598731: [bug #33829] SIGPIPE signal: wget over ssh orphans itself on ctrl+c

[Giuseppe Scrivano]

Update of bug #33829 (project wget):

  Status:None = Fixed  
 Assigned to:None = gscrivano  
 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

thanks, it is fixed now with the commit:

gscriv...@gnu.org-20110729134911-fx31kuy3n2v56bou

Cheers,
Giuseppe


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33829

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#595538: [bug #33822] [PATCH] don't use PATH_MAX (FTBFS on hurd)

[Giuseppe Scrivano]

Update of bug #33822 (project wget):

  Status:None = Fixed  
 Assigned to:None = gscrivano  
 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

thanks.  I have included the patch.

___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33822

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#597468: [bug #33828] info page points to not documented --cookies option

[Giuseppe Scrivano]

Update of bug #33828 (project wget):

  Status:None = Fixed  
 Assigned to:None = gscrivano  
 Open/Closed:Open = Closed 


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33828

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#564656: [bug #33826] doc: reference to Mozilla's cookie file is out of date

[Giuseppe Scrivano]

Update of bug #33826 (project wget):

  Status:None = Inspected  
 Assigned to:None = gscrivano  

___

Follow-up Comment #1:

but in this case, the browser version is specified.  While it is not true for
last versions of Mozilla browser, it is still valid for that old version.


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?33826

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#545422: coreutils: tail -f - fails

[Giuseppe Scrivano]

Hi Jim,

what do you think about the following solution?  It avoids to revert to
the old polling mechanism using /dev/stdin instead of - to
inotify_add_watch.

Cheers,
Giuseppe


diff --git a/src/tail.c b/src/tail.c
index e3b9529..016b712 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1152,6 +1152,12 @@ tail_forever (struct File_spec *f, size_t n_files, 
double sleep_interval)
 
 #if HAVE_INOTIFY
 
+static char const *
+map_inotify_fname (char const *name)
+{
+  return STREQ (name, -) ? /dev/stdin : name;
+}
+
 static size_t
 wd_hasher (const void *entry, size_t tabsize)
 {
@@ -1226,7 +1232,8 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t 
n_files,
 }
 }
 
-  f[i].wd = inotify_add_watch (wd, f[i].name, inotify_wd_mask);
+  f[i].wd = inotify_add_watch (wd, map_inotify_fname (f[i].name),
+  inotify_wd_mask);
 
   if (f[i].wd  0)
 {
@@ -1330,7 +1337,8 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t 
n_files,
   if (i == n_files)
 continue;
 
-  f[i].wd = inotify_add_watch (wd, f[i].name, inotify_wd_mask);
+  f[i].wd = inotify_add_watch (wd, map_inotify_fname (f[i].name),
+  inotify_wd_mask);
 
   if (f[i].wd  0)
 {




Jim Meyering j...@meyering.net writes:

 Bill Brelsford wrote:
 Package: coreutils
 Version: 7.5-3
 Severity: normal

 tail -f no longer works with stdin.  E.g. commands such as

  somecommand | tail -f -
  somecommand | tail -f
  tail -f /var/log/kern

 fail with the message:

  tail: cannot watch `-': No such file or directory

 Worked under 7.4-2 and previous versions.

 Thanks for the report.
 I'm fixing it like this, upstream.
 Test coming momentarily.

 From 30269c9ca38c06b31a7c764c192562e3b0268725 Mon Sep 17 00:00:00 2001
 From: Jim Meyering meyer...@redhat.com
 Date: Mon, 7 Sep 2009 08:37:08 +0200
 Subject: [PATCH] tail -f: work on - once again

 * src/tail.c (main) [HAVE_INOTIFY]: When stdin (i.e., -, but not
 /dev/stdin) is specified on the command line, don't use inotify.
 Reported by  Bill Brelsford in http://bugs.debian.org/545422.
 * NEWS (Bug fixes): Mention it.
 This bug was introduced in coreutils-7.5 via commit ae494d4b,
 2009-06-02, tail: use inotify if it is available.
 ---
  NEWS   |9 +
  src/tail.c |   14 +-
  2 files changed, 22 insertions(+), 1 deletions(-)

 diff --git a/NEWS b/NEWS
 index b02d2da..5c7fb82 100644
 --- a/NEWS
 +++ b/NEWS
 @@ -31,6 +31,15 @@ GNU coreutils NEWS-*- 
 outline -*-
Before, this would print nothing and wait: stdbuf -o 4K tail -f /etc/passwd
Note that this bug affects tail -f only when its standard output is 
 buffered,
which is relatively unusual.
 +  [bug introduced in coreutils-7.5]
 +
 +  tail -f once again works with standard input.  inotify-enabled tail -f
 +  would fail when operating on a nameless stdin.  I.e., tail -f  /etc/passwd
 +  would say tail: cannot watch `-': No such file or directory, yet the
 +  relatively baroque tail -f /dev/stdin  /etc/passwd would work.  Now, the
 +  offending usage causes tail to revert to its conventional sleep-based
 +  (i.e., not inotify-based) implementation.
 +  [bug introduced in coreutils-7.5]

  ** New features

 diff --git a/src/tail.c b/src/tail.c
 index e3b9529..c53df9e 100644
 --- a/src/tail.c
 +++ b/src/tail.c
 @@ -1982,7 +1982,19 @@ main (int argc, char **argv)
if (forever)
  {
  #if HAVE_INOTIFY
 -  if (!disable_inotify)
 +  /* If the user specifies stdin via a command line argument of -,
 + or implicitly by providing no arguments, we won't use inotify.
 + Technically, on systems with a working /dev/stdin, we *could*,
 + but would it be worth it?  Verifying that it's a real device
 + and hooked up to stdin is not trivial, while reverting to
 + non-inotify-based tail_forever is easy and portable.  */
 +  bool stdin_cmdline_arg = false;
 +
 +  for (i = 0; i  n_files; i++)
 +if (STREQ (file[i], -))
 +  stdin_cmdline_arg = true;
 +
 +  if (!disable_inotify  !stdin_cmdline_arg)
  {
int wd = inotify_init ();
if (wd  0)
 --
 1.6.4.2.419.gab238



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#545422: coreutils: tail -f - fails

[Giuseppe Scrivano]

Jim Meyering j...@meyering.net writes:

 I considered that and discussed the
 trade-off in the comment I committed.
 There have been systems and configurations with
 nonexistent and unusable /dev/stdin files.

sorry, I didn't read you comment.

This patch changes `tail' to handle stdin separately from inotify
events, similar to what we are already doing when a --pid is specified.

Regards,
Giuseppe


From f3010bebf9e25be9a83868b4ad9db2cc6cb6613f Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Mon, 7 Sep 2009 16:35:16 +0200
Subject: [PATCH] tail: handle - properly

* src/tail.c (tail_forever_inotify): Handle stdin (i.e., -, but not
/dev/stdin) separately from inotify.
* tests/tail-2/wait: Ensure that when a stdin is watched, tail does not
raise errors.
---
 src/tail.c|  176 ++---
 tests/tail-2/wait |6 ++
 2 files changed, 119 insertions(+), 63 deletions(-)

diff --git a/src/tail.c b/src/tail.c
index e3b9529..b817ecb 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -134,7 +134,7 @@ struct File_spec
   int errnum;
 
 #if HAVE_INOTIFY
-  /* The watch descriptor used by inotify.  */
+  /* The watch descriptor used by inotify, -1 on error, -2 if stdin.  */
   int wd;
 
   /* The parent directory watch descriptor.  It is used only
@@ -1184,6 +1184,7 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t 
n_files,
   char *evbuf;
   size_t evbuf_off = 0;
   size_t len = 0;
+  struct File_spec *stdin_spec = NULL;
 
   wd_table = hash_initialize (n_files, NULL, wd_hasher, wd_comparator, NULL);
   if (! wd_table)
@@ -1196,6 +1197,34 @@ tail_forever_inotify (int wd, struct File_spec *f, 
size_t n_files,
 {
   if (!f[i].ignore)
 {
+  if (STREQ (f[i].name, -))
+{
+  int old_flags = fcntl (f[i].fd, F_GETFL);
+  int new_flags = old_flags | O_NONBLOCK;
+
+  stdin_spec = f[i];
+  found_watchable = true;
+
+  if (old_flags  0
+  || (new_flags != old_flags
+   fcntl (f[i].fd, F_SETFL, new_flags) == -1))
+{
+  /* Don't update f[i].blocking if fcntl fails.  */
+  if (S_ISREG (f[i].mode)  errno == EPERM)
+{
+  /* This happens when using tail -f on a file with
+ the append-only attribute.  */
+}
+  else
+error (EXIT_FAILURE, errno,
+   _(%s: cannot change stdin nonblocking mode));
+}
+  f[i].blocking = false;
+  f[i].wd = -2;
+  prev_wd = f[i].wd;
+  continue;
+}
+
   size_t fnlen = strlen (f[i].name);
   if (evlen  fnlen)
 evlen = fnlen;
@@ -1235,6 +1264,8 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t 
n_files,
   continue;
 }
 
+  prev_wd = f[i].wd;
+
   if (hash_insert (wd_table, (f[i])) == NULL)
 xalloc_die ();
 
@@ -1245,8 +1276,6 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t 
n_files,
   if (follow_mode == Follow_descriptor  !found_watchable)
 return;
 
-  prev_wd = f[n_files - 1].wd;
-
   evlen += sizeof (struct inotify_event) + 1;
   evbuf = xmalloc (evlen);
 
@@ -1259,12 +1288,12 @@ tail_forever_inotify (int wd, struct File_spec *f, 
size_t n_files,
   struct File_spec *fspec;
   uintmax_t bytes_read;
   struct stat stats;
-
+  bool check_stdin = false;
   struct inotify_event *ev;
 
-  /* When watching a PID, ensure that a read from WD will not block
- indefinetely.  */
-  if (pid)
+  /* When watching a PID or stdin, ensure that a read from WD will not 
block
+ indefinitely.  */
+  if (pid || stdin_spec)
 {
   fd_set rfd;
   struct timeval select_timeout;
@@ -1284,78 +1313,92 @@ tail_forever_inotify (int wd, struct File_spec *f, 
size_t n_files,
 
   if (n_descriptors == 0)
 {
-  /* See if the process we are monitoring is still alive.  */
-  if (kill (pid, 0) != 0  errno != EPERM)
-exit (EXIT_SUCCESS);
+  if (stdin_spec)
+check_stdin = true;
+  if (pid)
+{
+  /* See if the process we are monitoring is still alive.  */
+  if (kill (pid, 0) != 0  errno != EPERM)
+exit (EXIT_SUCCESS);
 
-  continue;
+  if (!check_stdin)
+continue;
+}
 }
 }
 
-  if (len = evbuf_off)
+  if (check_stdin)
 {
-  len = safe_read (wd, evbuf, evlen);
-  evbuf_off = 0;
-
-  /* For kernels prior to 2.6.21, read returns 0 when the buffer
- is too small.  */
-  if ((len == 0

Bug#522331: iceweasel supports non-free plugins

[Giuseppe Scrivano]

Hello,

this is another idea that can be considered.  What do you think about an
additional package that once installed will change Iceweasel preferences
in a way to use only free plugins/addons?  Is is a reasonable option?

Thanks,
Giuseppe



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#522196: #522196 - RFP: gnu icecat - the GNU version of Mozilla Firefox

[Giuseppe Scrivano]

Hello,

Brett Parker idu...@sommitrealweird.co.uk writes:

 I thought they all now dynamically linked against xulrunner so that security
 support was much simpler than before, so it's really just a frontend more than
 a clone of firefox, no?

Yes, I think Iceweasel and Icecat can share xulrunner without problems.

After the discussion with Mike I think what is really important is the
possibility to use only free plugins and addons, no matter if Icecat or
Iceweasel.

Regards,
Giuseppe



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#522331: iceweasel supports non-free plugins

[Giuseppe Scrivano]

Mike Hommey m...@glandium.org writes:

 Ideally, we shouldn't be using either your nor upstream's datasource,
 but our own, that would point to debian packages first.

Is there any plan to suggest and use only Free plugins inside Iceweasel?

Regards,
Giuseppe



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#522331: iceweasel supports non-free plugins

[Giuseppe Scrivano]

It is not a complete solution yet, why non free packages should be
suggested to an user who decided to don't use the non-free repository?

Giuseppe


Mike Hommey m...@glandium.org writes:

 Placing debian packages that are in the main section first should be
 enough.

 Mike



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#522331: iceweasel supports non-free plugins

[Giuseppe Scrivano]

Package: iceweasel
Version: 3.0.7-1

what do you think about use the GNU GNUzilla project plugins finder
service instead of the current one?
This plugins finder service is already used by the GNU IceCat web
browser.  Differently from the plugins finder service used now that
suggests users to install non-free plugins, the GNUzilla service uses
only Free plugins.

It can be done easily using this line in the pref/firefox-branding.js
file:

pref (pfs.datasource.url, 
http://gnuzilla.gnu.org/plugins/PluginFinderService.php?mimetype=%PLUGIN_MIMETYPE%appID=%APP_ID%appVersion=%APP_VERSION%clientOS=%CLIENT_OS%chromeLocale=%CHROME_LOCALE%;);




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#522196: RFP: gnu icecat - the GNU version of Mozilla Firefox

[Giuseppe Scrivano]

Package: wnpp
Severity: wishlist
License: GNU General Public License v2 or later (+ dual licensing)

Gnuzilla is the GNU version of the Mozilla suite, and GNU IceCat is the
GNU version of the Firefox browser. Its main advantage is an ethical
one: it is entirely free software. While the source code from the
Mozilla project is free software, the binaries that they release include
additional non-free software. Also, they distribute and recommend
non-free software as plug-ins.

A non-official debian package is present here:

deb http://gnuzilla.gnu.org/download/debian deltah-icecat universe main
deb-src http://gnuzilla.gnu.org/download/debian deltah-icecat  universe main



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#288655: myserver_0.8.11-1_amd64.changes REJECTED

[Giuseppe Scrivano]

Paul Cager [EMAIL PROTECTED] writes:

 2)  How much less generic should the name be? E.g. would mywebserver be OK?

Can it be something like myserver-http or myserver-web?  mywebserver
sounds like a completely different name.

Regards,
Giuseppe



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]