[DNG] slashpackage?

[Steve Litt]

Hi all,

Daniel J Bernstein, known as djb, created a package manager, called
slashpackage, that uses the Unix file hierarchy as the package
manager's database. As far as I can see, it has the following
(dis)advantages:

ADVANTAGES:
* Less crazy than apt-get, yum, xbps, pacman, etc
* Always a determinate way to get to a file
* Used heavily in djb and djb-inspired software
* Requires no revision of "upstream" install scripts

DISADVANTAGES:
* Filesystem Hierarchy System (FHS) noncompliant directories /package
  and /command directly off the root.
* I've never seen any distro that would allow anything directly off the
  root besides /usr, /var, /home, /tmp, /opt, /sys, /proc, /dev, /run
* If everybody who thought they had a better idea were allowed to
  create their own directory directly off the root, the tree would be a
  zoo.

INFORMATION:
The following discuss the thought behind djb's slashpackage package
manager layout:

http://skarnet.org/cgi-bin/archive.cgi?2:mss:1802:201707:npmlmocljngkmhfamaic

https://cr.yp.to/slashpackage.html

http://thedjbway.b0llix.net/builddjb.html

https://cr.yp.to/slashpackage/management.html

https://www.skarnet.org/software/skalibs/flags.html


QUESTIONS TO PONDER:

* Do Debian djb style apps respect slashpackage,  and if so, do they
  all do it the same way in the same directories? If so, perhaps it's
  best for Devuan to do it the same way. If Debian djb style apps
  respect slashpackage but put its roots in all sorts of different
  places, Devuan should go its own way.

* I've heard Debian's runit will work right out of the box. If this is
  true, this would be an incentive to use the same directories as the
  Debian runit package. However, there's a runit-systemd package that I
  don't think Devuan would be in a position to install.

* How horrible would it be to have directories /command, /package and
  perhaps even /service? /command and /package are both pure
  slashpackage, and all three are available the instant the root
  partition is loaded.

* The s6 upstream installer has a choice as to whether to go
  slashpackage, and if so, in which directories (if not the
  original /command and /package)? I'll need to examine that.

I'll keep you up to date on all of this.

SteveT

Steve Litt 
June 2017 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[Hendrik Boom]

On Mon, Jul 03, 2017 at 10:45:29AM -0500, dev wrote:
> On 07/03/2017 10:40 AM, Evilham wrote:
> 
> 
> > That's the thing, we can do that :-) probably should, but the "right
> > way" (from a standards point of view) would be to actually allow those
> > names ^^ not to disallow them. So instead of modifying the way useradd
> > works, the way adduser works should be fixed (so, shadow).
> 
> That was easy ;) Seems to be a flag for that.

But they should work without the flag.  The flag will allow usernames 
that are *really* questinoable. 

-- hendrik

> 
> # adduser 0day --force-badname
> Allowing use of questionable username.
> Adding user `0day' ...
> Adding new group `0day' (1000) ...
> Adding new user `0day' (1000) with group `0day' ...
> Creating home directory `/home/0day' ...
> Copying files from `/etc/skel' ...
> Enter new UNIX password:
> ___
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[Hendrik Boom]

On Mon, Jul 03, 2017 at 04:36:30PM +0200, Evilham wrote:
> Hi there,
> 
> Am 03/07/2017 um 16:08 schrieb dev:
...
> > 
> > useradd 0day works on Devuan. adduser 0day does not. Which is correct?
> 
> I had this discussion yesterday, so here are my 2 cents :-).
> 
> It is quite inconsistent what a "valid username" is, apparently it has
> gotten better.
> 
> According to POSIX, a valid username may include: a-z, A-Z, 0-9, ., -, _
> Where "-" cannot appear at the beginning. There is no further
> restriction on the other chars.
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_435
> 
> So, useradd works because it's lower level, adduser does not, because it
> comes from shadow and they have more restrictions on what a valid name
> is. IMHO that's a bug in shadow.
> https://github.com/shadow-maint/shadow/blob/master/libmisc/chkname.c#L52
> 
> It is not possible, for example to execute: adduser name.lastname, which
> is a valid POSIX username (but useradd name.lastname works fine).

It's not clear to me whether this is a bug in the adduser that's been 
around for ages, or n a systemd replacement for it. 

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] kernel drivers [WAS: How long should I expect to wait for openrc to be ready in devuan ascii]

[Enrico Weigelt, metux IT consult]

On 07/01/17 22:50, Didier Kryn wrote:


Precisely, the domain of embedded devices is one where HW vendors
write drivers.


Most of the time you don't wanna use them. Especially not proprietary
ones. Just look eg. at fsl's gpu drivers: totally insecure and harmful.
(back when I read their adreno kernel patches, I've literally spit out
my coffe - easily exploitable (eg. userland can overwrite kernel memory
in various ways), not even trivial bound checks, horriby complicated,
practically unreadable. Written by somebody who obviously had no idea
what he's doing (there were even pieces of win32 code in there!).

Yes, a few chip vendors have actually some kernel folks on their
payroll, but usually just for the very low level stuff.

Board/SOM vendors usually aren't much better (with a few exceptions).
Industrial computer vendors like NI tend to be even worse. NI doesn't
even have kernel drivers for their crio modules . everything's supposed
to be done w/ Labview.

BTW: did any embedded GPU vendor (except perhaps Intel) ever publish
full specs and proper (free and mainline'able) drivers ?


Motorolla/Emerson used to provide VME drivers for free,
but OOT despite the fact that the specs of the Tundra PCI-VME bridge
were public. They didn't do it for all releases.


Why didn't the work with the community to get everything upstream ?


Lesson learned: never ever buy NI.

I learned that lesson. They provide proprietary drivers and Labview
for some versions of RedHat or Suze and only Labview knows how to talk
to them. The device was never used.


I would have demanded my money back.

BTW: several weeks ago, I had an interesting call w/ several NI folks
(PR, sales, engineering, etc) about the driver situation, especially
for cRIO (which one of my client planned to use). Short summary: they
just dont have any drivers for the cards all. It's Labview-only, and
it's deeply twisted between FPGA+cpu - IOW: there aren't even defined
interfaces. They claimed they understood the problem, but still nothing
usable happended here. IOW: the actual decision makers still didn't
understand.


--mtx

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Beware the Icedove to Thunderbird transition

[marcus]

On 02/07/17 06:23 PM, Adam Borowski wrote:

On Sun, Jul 02, 2017 at 01:05:06PM -0400, Clark Sideroad wrote:

My advice: back-up everything related


Bad advice: just do the upgrade normally without any special precautions,
and if your special non-standard $Element$Bird setup gets borked, just
recover from backups you do anyway.  No special backup before an operation
as disruptive as upgrading between De??an releases is needed either, as you,
like anyone without a data loss wish, already backup at least daily.



You are right.
If I did as you say and I say and back up every day, I would be OK.

Then I could have done it again and again until I figured out the 
purpose of the .migrated file.


"This file is automatically created by /usr/bin/thunderbird, it will be
created on every start of Thunderbird if does not exist.
Remove that file only if you know the propose of this file."

In my case of stupidity the backup was a week old, the cat laughed too.
I probably should have added the .migrated file before I learned of it 
post script. (-;


--
Clarke
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] devuan packages explorer

[golinux]

On 2017-07-03 18:13, Gionni FireGarden wrote:

hi all!
by now we don't have a place like packages.debian.org [1] or
packages.ubuntu.com [2] so i create with a friend a PoC for that.
We work on this idea just two nights, after work: it's really a
primitive Proof of Concept so please be merciful [gh], but we are
improving day by day.
The system is composed by a python parser job that import all packages
info from apt lists files into a mariadb and a bit of php to render
that on web.
No framework used, no ORM: we create little libs for db and templating
[to avoid spaghetti code], very KISS & DRY so it will be easy mantain
this code... i hope :D

you can find what we have done here
http://devuanpackages.viralds.it [3]

do you like the idea? and this primitive implementation?
if you have any hints or suggests or bad words: we are here :)

thanks to all for the great work with devuan.

firegarden

Links:
--
[1] http://packages.debian.org
[2] http://packages.ubuntu.com
[3] http://devuanpackages.viralds.it




I heard that this was in the works.  Yes, it is much needed.  But I 
don't see it as part of the main website.  IMO, it would be better to 
have that DB on a separate site with its own url (good for search 
engines) that could be linked to from devuan.org and other Devuan 
related sites.  I would also vote for a sparser, more compact look with 
the nav bar linking to various aspects of the DB structure.


golinux


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd: good riddance!

[Enrico Weigelt, metux IT consult]

On 07/01/17 21:21, Simon Hobson wrote:


In general - none !


So, why not just patching the crap out and filing an upstream bug
(incl. notifying the folks here, so we can keep an eye on it) ?

--mtx

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] devuan packages explorer

[Ozi Traveller]

Awesome I've been hoping for this to happen! :)

A filtering function would also be good eg. release=ascii, architecture=i386

ozi

On Tue, Jul 4, 2017 at 9:50 AM, Evilham  wrote:

> Hey!
>
> Am 04/07/2017 um 1:13 schrieb Gionni FireGarden:
> > The system is composed by a python parser job that import all packages
> > info from apt lists files into a mariadb and a bit of php to render that
> > on web.
> > No framework used, no ORM: we create little libs for db and templating
> > [to avoid spaghetti code], very KISS & DRY so it will be easy mantain
> > this code... i hope :D
> >
> > you can find what we have done here
> > http://devuanpackages.viralds.it
> >
> > do you like the idea? and this primitive implementation?
> > if you have any hints or suggests or bad words: we are here :)
> >
> > thanks to all for the great work with devuan.
>
> Quite cool! I was just asking about this yesterday and intended to give
> it a shot at some point ^^.
>
> A couple remarks:
> - Packages are not sorted alphabetically, which makes for a weird
> navigation.
> - It'd be useful to show the package version as well. See:
> https://git.devuan.org/devuan-editors/devuan-www/issues/148
> - A search function would also be quite useful :-).
> - Probably showing a box for each page makes not much sense, I think the
> usual solution for this is a few buttons for pages around the current
> one and an input field that allows the user to write which page they
> want to visit.
> --
> Evilham
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] devuan packages explorer

[Gionni FireGarden]

hi all!
by now we don't have a place like packages.debian.org or packages.ubuntu.com
so i create with a friend a PoC for that.
We work on this idea just two nights, after work: it's really a primitive
Proof of Concept so please be merciful [gh], but we are improving day by
day.
The system is composed by a python parser job that import all packages info
from apt lists files into a mariadb and a bit of php to render that on web.
No framework used, no ORM: we create little libs for db and templating [to
avoid spaghetti code], very KISS & DRY so it will be easy mantain this
code... i hope :D

you can find what we have done here
http://devuanpackages.viralds.it

do you like the idea? and this primitive implementation?
if you have any hints or suggests or bad words: we are here :)

thanks to all for the great work with devuan.


firegarden
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Listserver configuration

[G.W. Haywood]

Hi there,

On Mon, 3 Jul 2017, Antony Stone wrote:
On Monday 03 July 2017 at 22:27:44, Gregory Nowak wrote:

> On Mon, Jul 03, 2017 at 07:09:29PM +0200, Joachim Fahrner wrote:
>
> > I get lots of those errors in my postfix log:
> >
> > Jul  3 18:09:16 server postfix/smtpd[2840]: NOQUEUE: reject: RCPT
> > from tupac2.dyne.org[178.62.188.7]: 450 4.7.1 :
> > Helo command rejected: Host not found;
> > from= to= proto=ESMTP
> > helo=
> >
> > Is there some configuration problem with the list mail server?
>
> I'm not seeing this here, and the A record for tupac2.dyne.org
> resolves correctly. Could there be a DNS issue on your end perhaps?

tupac2.dyne.org resolves here perfectly well too, however surely the problem
being reported by that error message is that the machine tupac2.dyne.org
cannot resolve fahrner.name (which also resolves here perfectly okay)?


No, the issue does seem to at or before the 'helo' command stage, but
the error message isn't terribly clear to me because I'm a Sendmail
user. :/  Whatever isn't found (presumably not found by the DNS server
which Postfix is using) it isn't the envelope recipient, which has not
been established at the 'helo' stage.

The nameservers for dyne.org look fine, and I see no problems (in the
UK, with Sendmail & BIND).

In a case like this I'd look at my nameserver logs.  If you don't use
a local nameserver you could set up a caching-only server just so it
can log things.  That might even fix the probelm. :)  Alternatively you
could run a tool like tcpdump to record the traffic and then display
it e.g. with Ethereal.

--

73,
Ged.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Listserver configuration

[Antony Stone]

On Monday 03 July 2017 at 22:27:44, Gregory Nowak wrote:

> On Mon, Jul 03, 2017 at 07:09:29PM +0200, Joachim Fahrner wrote:
> > I get lots of those errors in my postfix log:
> > 
> > Jul  3 18:09:16 server postfix/smtpd[2840]: NOQUEUE: reject: RCPT
> > from tupac2.dyne.org[178.62.188.7]: 450 4.7.1 :
> > Helo command rejected: Host not found;
> > from= to= proto=ESMTP
> > helo=
> > 
> > Is there some configuration problem with the list mail server?
> 
> I'm not seeing this here, and the A record for tupac2.dyne.org
> resolves correctly. Could there be a DNS issue on your end perhaps?

tupac2.dyne.org resolves here perfectly well too, however surely the problem 
being reported by that error message is that the machine tupac2.dyne.org 
cannot resolve fahrner.name (which also resolves here perfectly okay)?


Antony.

-- 
Roses are red,
Bacon is too,
Poetry's hard,
Bacon.
with thanks to Claire Davison

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Listserver configuration

[Gregory Nowak]

On Mon, Jul 03, 2017 at 07:09:29PM +0200, Joachim Fahrner wrote:
> I get lots of those errors in my postfix log:
> 
> Jul  3 18:09:16 server postfix/smtpd[2840]: NOQUEUE: reject: RCPT
> from tupac2.dyne.org[178.62.188.7]: 450 4.7.1 :
> Helo command rejected: Host not found;
> from= to= proto=ESMTP
> helo=
> 
> Is there some configuration problem with the list mail server?

I'm not seeing this here, and the A record for tupac2.dyne.org
resolves correctly. Could there be a DNS issue on your end perhaps?

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] on the supposed grsec gpl violation

[Bruce Perens]

On Mon, Jul 3, 2017 at 4:31 AM, Jaromil  wrote:

> I first thought grsec was not in GPL violation, but then in your last
> 3 mails and this one you made the point very clear and I'm more than
> half-way convinced (yet my opinion is of little value here, IANAL nor
> a scholar in law)
>

It's getting the time sequence right that makes the difference. An
expectation that the business will be damaged by Grsecurity shutting off
their service, in consequence of exercise of their GPL right to
redistribute, exists *before *the act of distribution. It took me a while
to get that right.

It would be much harder to prove if they hadn't warned people and made this
policy known to many people, and if they just incidentally disconnected a
customer after a single act of distribution without the context to show
that it was a known policy of the company.

If this actually got to court, it would be necessary to depose people about
the policy in order to show that customers knew in advance. But I'm pretty
confident that Grsecurity would be found in violation.


>
> Are there other cases in which a license (whatever license) has been
> breached (and ruled as broken) by such a business arrangement?
>

 I don't have a precedential case yet. I suspect one could be found.

Thanks

Bruce
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[Bruce Perens]

Hi Miroslav,

I am well aware that Google is a big company, and like all big companies
they can function in an unethical manner. There are no exceptions. I catch
SpaceX in lies and omissions all of the time even though I obviously admire
what they are doing with rockets.

I worked for their outside counsel as a case strategist in Oracle v.
Google, mostly collecting evidence that Sun had in its time committed all
of the acts that Oracle was accusing Google of committing with Sun's
software. In this case, Google's defense was in the interest of Free
Software. I wasn't allowed to go on the stand because of a blog posting I'd
previously written that they didn't want me questioned upon, so they
replaced me with Nimmer. If you're going to be replaced, being replaced by
Nimmer, who is cited by courts an incredible number of times, isn't bad.

It is true that we are taken advantage of by big companies. But the ones
which really irk me are the ones who disregard the license like VMWare, and
lately Grsecurity. It happens that some of these companies have paid me to
fix their problems and come into compliance.

Our licenses are the rules we made. They are the only things we really have
a right to expect people to follow. Google is pretty good about following
the rules, and if ever I think they aren't, I have access to management and
can fix it.

Grsecurity's complaint is that they made free software, and people aren't
doing what they want with it. So, they became a proprietary business. But
note that they didn't even develop a trademark for their proprietary
product that is different from the Free Software, because their product is
the Free Software. I am fine with their being a proprietary business as
long as they don't try to take Free Software private while they're doing
it, or make proprietary derivative works of Free Software - and of course
that's just what they are doing.

If they want to be proprietary, they should make a security product that
isn't so interleaved with Linux that it can't help but be in violation, or
they should make it for the BSD kernel where they can fit into the rules. I
can't work up any sympathy for them until they do that or find some means
of distributing their product that doesn't so clearly break the rules.

Thanks

Bruce
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Listserver configuration

[Joachim Fahrner]

Hello,
I get lots of those errors in my postfix log:

Jul  3 18:09:16 server postfix/smtpd[2840]: NOQUEUE: reject: RCPT from 
tupac2.dyne.org[178.62.188.7]: 450 4.7.1 : Helo command 
rejected: Host not found; from= 
to= proto=ESMTP helo=


Is there some configuration problem with the list mail server?

Jochen

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[d_pridge]

When was that option added?


Sent from my MetroPCS 4G LTE Android Device
 Original message From: Evilham  Date: 
7/3/17  11:03 AM  (GMT-06:00) To: dng@lists.dyne.org Subject: Re: [DNG] systemd 
allows elevated access from unit files? 
Am 03/07/2017 um 17:57 schrieb KatolaZ:
> On Mon, Jul 03, 2017 at 10:45:29AM -0500, dev wrote:
>> On 07/03/2017 10:40 AM, Evilham wrote:
>> 
>>
>>> That's the thing, we can do that :-) probably should, but the "right
>>> way" (from a standards point of view) would be to actually allow those
>>> names ^^ not to disallow them. So instead of modifying the way useradd
>>> works, the way adduser works should be fixed (so, shadow).
>>
>> That was easy ;) Seems to be a flag for that.
>>
>> # adduser 0day --force-badname
>> Allowing use of questionable username.
>> Adding user `0day' ...
>> Adding new group `0day' (1000) ...
>> Adding new user `0day' (1000) with group `0day' ...
>> Creating home directory `/home/0day' ...
>> Copying files from `/etc/skel' ...
>> Enter new UNIX password:
> 
> When you think to have found something totally wrong in unix, you most
> probably have not looked deep enough :)

Yeah, there's also some env var that can be set. My point was taht the
names are not allowed by default with some tools but with others they
are and they are OK according to the standard, and that makes it quirky.

Although I think it'd be better if they were allowed by default
(consistency + standard compliance), TBH I'd be totally ok with not
touching either adduser nor useradd; it's only an issue with disastrous
decisions somewhere else.
-- 
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[Joachim Fahrner]

Am 2017-07-03 17:34, schrieb dev:
useradd and adduser work differently. One allows it, the other does 
not.

Just thought 'why not make them work the same?'. That's all.


That's right, that's a bug. They should work the same, and they should 
follow POSIX-rules, not Poettering-rules.


Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[Evilham]

Am 03/07/2017 um 17:57 schrieb KatolaZ:
> On Mon, Jul 03, 2017 at 10:45:29AM -0500, dev wrote:
>> On 07/03/2017 10:40 AM, Evilham wrote:
>> 
>>
>>> That's the thing, we can do that :-) probably should, but the "right
>>> way" (from a standards point of view) would be to actually allow those
>>> names ^^ not to disallow them. So instead of modifying the way useradd
>>> works, the way adduser works should be fixed (so, shadow).
>>
>> That was easy ;) Seems to be a flag for that.
>>
>> # adduser 0day --force-badname
>> Allowing use of questionable username.
>> Adding user `0day' ...
>> Adding new group `0day' (1000) ...
>> Adding new user `0day' (1000) with group `0day' ...
>> Creating home directory `/home/0day' ...
>> Copying files from `/etc/skel' ...
>> Enter new UNIX password:
> 
> When you think to have found something totally wrong in unix, you most
> probably have not looked deep enough :)

Yeah, there's also some env var that can be set. My point was taht the
names are not allowed by default with some tools but with others they
are and they are OK according to the standard, and that makes it quirky.

Although I think it'd be better if they were allowed by default
(consistency + standard compliance), TBH I'd be totally ok with not
touching either adduser nor useradd; it's only an issue with disastrous
decisions somewhere else.
-- 
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[KatolaZ]

On Mon, Jul 03, 2017 at 10:45:29AM -0500, dev wrote:
> On 07/03/2017 10:40 AM, Evilham wrote:
> 
> 
> > That's the thing, we can do that :-) probably should, but the "right
> > way" (from a standards point of view) would be to actually allow those
> > names ^^ not to disallow them. So instead of modifying the way useradd
> > works, the way adduser works should be fixed (so, shadow).
> 
> That was easy ;) Seems to be a flag for that.
> 
> # adduser 0day --force-badname
> Allowing use of questionable username.
> Adding user `0day' ...
> Adding new group `0day' (1000) ...
> Adding new user `0day' (1000) with group `0day' ...
> Creating home directory `/home/0day' ...
> Copying files from `/etc/skel' ...
> Enter new UNIX password:

When you think to have found something totally wrong in unix, you most
probably have not looked deep enough :)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[dev]

On 07/03/2017 10:40 AM, Evilham wrote:


> That's the thing, we can do that :-) probably should, but the "right
> way" (from a standards point of view) would be to actually allow those
> names ^^ not to disallow them. So instead of modifying the way useradd
> works, the way adduser works should be fixed (so, shadow).

That was easy ;) Seems to be a flag for that.

# adduser 0day --force-badname
Allowing use of questionable username.
Adding user `0day' ...
Adding new group `0day' (1000) ...
Adding new user `0day' (1000) with group `0day' ...
Creating home directory `/home/0day' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[Evilham]

Am 03/07/2017 um 17:34 schrieb dev:
> On 07/03/2017 10:17 AM, Evilham wrote:
>> Am 03/07/2017 um 17:06 schrieb dev:
>>> Would this be a good case to dis-allow ^0-9 by default but add a switch
>>> to allow it?
>>
>> What's the case for disallowing those at all? names starting with a
>> digit _are_ valid usernames.
> 
> 
> useradd and adduser work differently. One allows it, the other does not.
> Just thought 'why not make them work the same?'. That's all.

That's the thing, we can do that :-) probably should, but the "right
way" (from a standards point of view) would be to actually allow those
names ^^ not to disallow them. So instead of modifying the way useradd
works, the way adduser works should be fixed (so, shadow).

> 
> Yes, seems to me it would be a patch with upstream, not Devuan. Most
> likely this whole thing pointless since AD and SAMBA would break because
> of changing it. :/
> 

I think allowing those previously disallowed users in shadow would not
have a negative influence on AD / SAMBA integrations, maybe even a
positive one. (Plus: better OS consistency).
-- 
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[dev]

On 07/03/2017 10:17 AM, Evilham wrote:
> Am 03/07/2017 um 17:06 schrieb dev:
>> Would this be a good case to dis-allow ^0-9 by default but add a switch
>> to allow it?
> 
> What's the case for disallowing those at all? names starting with a
> digit _are_ valid usernames.


useradd and adduser work differently. One allows it, the other does not.
Just thought 'why not make them work the same?'. That's all.


> Is this at all an issue in Devuan, given that we have no systemd? I
> think the fix would be more appropriate as a patch to shadow, so that
> the behaviour is consistent (e.g. usernames with dots and dashes or,
> yes, starting with a digit allowed).


Yes, seems to me it would be a patch with upstream, not Devuan. Most
likely this whole thing pointless since AD and SAMBA would break because
of changing it. :/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[Evilham]

Am 03/07/2017 um 17:06 schrieb dev:
> Would this be a good case to dis-allow ^0-9 by default but add a switch
> to allow it?

What's the case for disallowing those at all? names starting with a
digit _are_ valid usernames.

It is an issue with systemd (and, to a different extent, shadow), we
shouldn't deviate further from the standard because of that.

Is this at all an issue in Devuan, given that we have no systemd? I
think the fix would be more appropriate as a patch to shadow, so that
the behaviour is consistent (e.g. usernames with dots and dashes or,
yes, starting with a digit allowed).

(sorry, had only replied to dev)
-- 
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[dev]

On 07/03/2017 09:58 AM, Rowland Penny wrote:


> 
> The problem is, '0day' is a perfectly acceptable name in Active
> Directory and that includes a Samba AD.

Would this be a good case to dis-allow ^0-9 by default but add a switch
to allow it?


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[Rowland Penny]

On Mon, 3 Jul 2017 09:54:27 -0500
dev  wrote:

> 
> On 07/03/2017 09:36 AM, Evilham wrote:
> > Hi there,
> > 
> 
> > 
> > (Maybe we should file a bug on bugs.devuan.org + bugs.debian.org +
> > shadow repo against shadow?)
> > 
> 
> Seems pretty straightforward to patch chkname.c feel free to include
> the patch if anyone does:
> 
> 

The problem is, '0day' is a perfectly acceptable name in Active
Directory and that includes a Samba AD.

Rowland
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd allows elevated access from unit files?

[Joachim Fahrner]

Am 2017-07-03 16:08, schrieb dev:

Sounds like a "won't fix", too:

  "So, yeah, I don't think there's anything to fix in systemd here."
   - Poettering

Not sure what's more troubling here[1]; the lack of concern, the
digression from POSIX, or the bug/backdoor itself. Maybe all three.

useradd 0day works on Devuan. adduser 0day does not. Which is correct?


According to POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_437

the only restriction is, the name should not begin with a hyphen.

Some systems have more restrictions, but that is not a must.
http://www.circlingcycle.com.au/fun-projects/IEEE-Std-1003.1-2001-and-valid-characters-usernames.html

Jochen
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] systemd allows elevated access from unit files?

[dev]

Sounds like a "won't fix", too:

  "So, yeah, I don't think there's anything to fix in systemd here."
   - Poettering

Not sure what's more troubling here[1]; the lack of concern, the
digression from POSIX, or the bug/backdoor itself. Maybe all three.

useradd 0day works on Devuan. adduser 0day does not. Which is correct?

[1] https://github.com/systemd/systemd/issues/6237
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Arnt Karlsen]

On Mon, 3 Jul 2017 02:00:22 +0200, Alessandro wrote in message 
<20170703020022.7ede7fb3@ayu>:

> On Mon, 3 Jul at 2017 01:03:13 +0200
> Arnt Karlsen  wrote:
> 
> > On Mon, 3 Jul 2017 00:42:52 +0200, Alessandro wrote in message 
> > <20170703004252.748a9c7f@ayu>:
> > 
> >> Il giorno Wed, 28 Jun 2017 19:38:11 +0200
> >> Didier Kryn  ha scritto:
> >>
> >>> Le 28/06/2017 à 15:40, Stephan Seitz a écrit :  
> >>> > And today you should always encrypt your discs. 
> >>>
> >>>  I don't see any reason to encrypt /usr. You might like to
> >>> encrypt /etc because it contains user names and (already
> >>> encrypted) passwords. But definitely there is no reason to
> >>> encrypt everything.  
> >> 
> >>   Valid reasons to encrypt /usr include:
> >> 
> >> 1) /usr resides on the same partition as / and/or /home (trivial
> >> case); 2) protecting its files from being tampered with when the
> >> device is offline;
> >> 3) making harder to someone who can access your
> >> offline HD understand which partition is /, or /usr or /home, so
> >> that the attacker will have to try to decrypt them all;
> >> 4) you put stuff in /usr/local that might contain
> >> keys/passwords/sensitive information that would better be kept
> >> protected.  
> >
> > ..if you wanna protect /usr/local, chop that off /usr and 
> > encrypt, mount etc them all as you damned please.
> 
>   /usr/local was standardized for a reason.  You might do as you like
> on your personal PC, maybe you're not as free to do the same on your
> company's server/workstation.

..a corner case might be company centralized maintenance on hardware
where you mount your handy encrypted /usr/local, /opt, /home/arnt etc
while keeping the company un-encrypted hardware accessible for e.g.
airport etc 'Securitate.'

>  You might have /opt bind-mounted
> on /usr/local, and have lots of stuff there you don't want to peruse
> to see if any of it would better be kept away from prying eyes (like
> VM images). What specific reasons do you have *not* to encrypt /usr
> in a machine that has / and /home encrypted?  What do you gain by
> that? 

..not much, all valid reasons to encrypt.
On Mon, 3 Jul 2017 02:20:22 +0200, Alessandro wrote in message 
<20170703022022.2e7ff012@ayu>:
>   I forgot to mention: leaking your collection of installed software
> is sometimes itself leaking personal and possibly sensitive
> information about yourself and your business, for the same reasons
> TCP/IP traffic metadata is important in it's own right.

..precisely, can easily be done by e.g. airport etc 'Securitate' or 
by your own network traffic.

> Plus, if you travel extensively, you might not know if the place
> you're traveling into has enacted some restrictions on the kind of
> software you are allowed to own and run.

..precisely, is why you research upfront and plan ahead, even 
for tin foil kinda stuff ... oh wait, who's #45? ;oD

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] on the supposed grsec gpl violation

[Jaromil]

dear Bruce,


On Sun, 02 Jul 2017, Bruce Perens wrote:

>This might make a little more sense if you still can't
>understand: By operating under their previously-stated policy of
>denying further service to clients who exercise their right to
>distribute under the GPL license, Open Source Security
>Inc. creates an expectation that exercise of the re-distribution
>right required under the terms of the  GPL will lead to business
>damage to the customer. This practice effectively is an added
>term to the license, and addition of such a term is prohibited
>under language in GPL section 6. This leads to termination of the
>GPL license granted to Open Source Security Inc., and thus to
>copyright infringement of the Linux Kernel by that entity. In
>addition, the GPL is breached as a contract from the copyright
>holders of the Linux software to which Open Source Security
>Inc. and the customer are both joined.


I first thought grsec was not in GPL violation, but then in your last
3 mails and this one you made the point very clear and I'm more than
half-way convinced (yet my opinion is of little value here, IANAL nor
a scholar in law)

Are there other cases in which a license (whatever license) has been
breached (and ruled as broken) by such a business arrangement?

My "feeling" is that this case breaks the GPL license especially
because the client can demonstrate that, by exercising his/her rights
granted by the license, a damage is caused by a business arrangement
enforced by those who distributed the software under that very
license.

it is overall an interesting case which may or may not confirm the
viability of a new (is it new?) business model in open source.

thanks for the forthcoming article post btw, will read it.

ciao
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] some ASCII issues

[Alessandro Selli]

On Sun, 2 Jul 2017 at 17:51:48 -0700
Rick Moen  wrote:

> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>> It cannot work if what you need to do is feeding the HD controller some
>> proprietary firmware that cannot legally be embedded in the GPL driver.
>
> ITYM that the resulting derivative work cannot be lawfully
> redistributed.  But compiling the driver does not redistribute it.

  Devuan in a public, general-purpose distribution, not an OS tailored to the
specific environment of a single individual's HW/layout.

> (I'm not necessarily endorsing your view about proprietary firmware.

  It's not *my* view, it's the law, it's the real world out there.

> I'm just pointing out that your conclusion doesn't follow from the
> premise.)

  They are not *my* conclusions, they are real-world issues.  The fact they
never impacted your operations does not make them neither inexistant nor
irrelevant.

  If you disagree, kindly point out what other method is available that
allows a kernel to lawfully feed a controlelr a firmware before mounting the
root FS.


-- 
Alessandro Selli http://alessandro.route-add.net
VOIP SIP: dhatarat...@ekiga.net
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I have a question about libsystemd0 in devuan ascii,

[Miroslav Rovis]

On 170702-17:22-0700, Bruce Perens wrote:
> This might make a little more sense if you still can't understand:
> 
> By operating under their previously-stated policy of denying further
> service to clients who exercise their right to distribute under the GPL
> license, Open Source Security Inc. creates an expectation that exercise of
> the re-distribution right required under the terms of the  GPL will lead to
Just taking note of the supposed herewith:
> business damage to the customer.
expressed care for users of the Linux kernel, which is users of all GNU/Linuces
distros.
> This practice effectively is an added term
> to the license, and addition of such a term is prohibited under language in
> GPL section 6. This leads to termination of the GPL license granted to Open
> Source Security Inc., and thus to copyright infringement of the Linux
> Kernel by that entity. In addition, the GPL is breached as a contract from
> the copyright holders of the Linux software to which Open Source Security
> Inc. and the customer are both joined.

And Schmoog the Schmoogle taking over the control of security of Linux, which
is being happening, which has been happening since the
(for-that-purpose-founded) inception of the KSPP-project... Look at even the
icon! It's a parody on PaX's icon, only KSPP looks like a freaking idiotic
cop...

And Schmoog the Schmoogle taking over the control of security of Linux, who
cares about that! Let's beat the poor! And for the rich!

And the fact that those two "poor" (only in comparison, I sincerely hope grsec
guys are not really poor as I am currently, which means, surviving on a few
hundred euros per month total, but only poor in comparison to the relatively
luxurient living Mr Linus, the guy who keeps releasing bad kernels to us
all)...

[And the fact that those two "poor"] have done the golden contribution to the
machine inside the OS, the kernel of all GNU/Linuces, who cares about that...

You are the principal author of DFSG. And all the fundaments of Free Software
and related movements shine to me as if I were reading what was thought of and
written in the stars and not on the Earth, and to get to read basically
bike-shedding criticism of grsecurity when the injustice that cries to God is
what spender wrote about, in the real news of this thread
(
this thread that ought to have remained under subject:

grsecurity ripoff by Google, with Linus' approval WAS: I have a question about 
libsystemd0 in devuan ascii

but, in what looks like, and may and may not have been so, a move to divert
attention from the subject of discussion, while staying with it --but in
defence of the Schmoog, and of Mr Linux-- so at the cost of keeping a
completely non-related subject for more emails to follow in reply: yes I'm
talking about this apparent diversion at the aforementioned cost:
< same subject as this email, kept to this email to keep in the thread >
https://lists.dyne.org/lurker/message/20170627.231950.12bf1f5c.en.html
It is as described above because it followed --just not by replying to it--
this email:
grsecurity ripoff by Google, with Linus' approval WAS: I have a question about 
libsystemd0 in devuan ascii,
https://lists.dyne.org/lurker/message/20170627.120949.727e804b.en.html
( where the subject line is perfectly appropriately changed, and even the "with
Linus' approval" holds, although it's more likely "Linus in cahoots", but no
proof of that, and "approval" is mild enough )
)

Yes, [to get to read basically bike-shedding criticism of grsecurity when the
injustice that cries to God is the truth that spender wrote, in the real news
of this thread] is very sad, to read so from the principal author of DFSG.

I'll repeat the news with more of my comments, but, first, I strongly believe
that there is not much to add about the alleged GPL license infringement by
Open Source Security Inc. after what Rick Moen wrote in one of his replies to
you, Bruce.

I will now, for clarity, insert from that quoted message into this email:

On 170627-22:22-0700, Rick Moen wrote:
> Quoting Bruce Perens (br...@perens.com):
> 
> > I did offer to discuss the case with companies and their counsel,
> > under NDA, without charge. In addition, I just added to the article
> > parenthetically that I am willing to discuss why fair-use does not
> > apply, but would not complicate that article with it.
> 
> Makes sense.
...
> 
> > > The key bit is your sentence 'GPL version 2 section 6 explicitly
> > > prohibits the addition of terms such as this redistribution
> > > prohibition', which does not accord with my own understanding of that
> > > clause or of pragmatic copyright caselaw -- as I've said.
> > 
> > 
> > OK. I just read it again:
> > 
> >  6. Each time you redistribute the Program (or any work based on the
> > Program), the recipient automatically receives a license from the
> > original licensor to copy, distribute or modify the Program subject to
> > these terms and conditions.  You may not impose any further 

Re: [DNG] Error updating ascii today

[KatolaZ]

On Sun, Jul 02, 2017 at 01:14:26PM +0100, Vincent Bentley wrote:
> I tried again using: sudo apt update
> 
> Get:1 http://packages.devuan.org/merged ascii InRelease [113 kB]
> Err:1 http://packages.devuan.org/merged ascii InRelease
>   Couldn't create temporary file /tmp/apt.conf.r8vXm3 for passing config
> to apt-key
> Reading package lists... Done
> W: GPG error: http://packages.devuan.org/merged ascii InRelease:
> Couldn't create temporary file /tmp/apt.conf.r8vXm3 for passing config
> to apt-key
> E: The repository 'http://packages.devuan.org/merged ascii InRelease' is
> not signed.
> N: Updating from such a repository can't be done securely, and is
> therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user
> configuration details.

I don't know whether it's relevant, but apt keeps ranting about not
being able to create a temporary file under /tmp. Are you sure you
have enough space there?

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng