• kdevel (15/15) Apr 08 2019 Examples:
• David Nadlinger (9/11) Apr 08 2019 Is this actually an issue? I agree 0:0 would be a bit cleaner, but what
• kinke (6/10) Apr 08 2019 As far as I understand, this is by default only a concern when

kdevel <kdevel vogtner.de> writes:

Examples:

- drwxrwxrwx vsts/docker       0 2019-04-06 19:09 
ldc2-1.15.0-linux-x86_64/etc/

   issues:

      · directory not root:root owned
      · directory group and world writable

- -rwxrwxrwx 1001/117    1552408 2019-04-06 19:10 
ldc2-1.15.0-linux-x86_64/bin/ddemangle


   issues:

      · file not root:root owned
      · file group and world writable

vsts/docker is uid/gid 1001/117. If you untar the tarball the 
files are created with this uid/gid.

Expected: All files and directories have uid/gid 0/0 (root/root) 
and are not group and not world writable.

"David Nadlinger" <code klickverbot.at> writes:

Hi,

On 8 Apr 2019, at 18:52, kdevel via digitalmars-d-ldc wrote:
      · directory not root:root owned
      · directory group and world writable

Is this actually an issue? I agree 0:0 would be a bit cleaner, but what 
are the situations where this isn't easily fixed after extraction? The 
release configuration is at 
https://github.com/ldc-developers/ldc/blob/master/shippable.yml, if 
you'd like to submit a pull request.

Best,
David

kinke <noone nowhere.com> writes:

On Monday, 8 April 2019 at 21:54:05 UTC, David Nadlinger wrote:
 Is this actually an issue? I agree 0:0 would be a bit cleaner, 
 but what are the situations where this isn't easily fixed after 
 extraction? The release configuration is at 
 https://github.com/ldc-developers/ldc/blob/master/shippable.yml, if you'd like
to submit a pull request.

As far as I understand, this is by default only a concern when 
extracting as root. Anway, PR is already up (for Azure, as that's 
the culprit; Shippable is unchanged and exactly as desired - 0:0 
and 644/755): https://github.com/ldc-developers/ldc/pull/3056

Thanks  kdevel for noticing, although a bit too late. ;)