-----BEGIN PGP SIGNED MESSAGE-----Scripts will always be necessary unless you have a purpose built system that never gets updated or relocated, and never has any changes to the hardware (and guess what, you use scripts constantly if you use the command-line, option syntax and configuration files are technically domain-specific scripting languages).
Hash: SHA512
Am Mo den 9. Nov 2015 um 17:28 schrieb Austin S Hemmelgarn:
Having some scripts in the process is definitively a nightmare toIt's still unavoidable in a number of cases. It's easy to re-write scripts
control. That should be prevented wherever possible. And usually it is
as the scripts might be used for computing some values that are used
later in privileged stuff.
to fit any local configuration. It's not anywhere near as easy to re-write
a compiled program to account for any local configuration.
I would not only say that it is avoidable, it is the worst that can
happen.
Unless you need the binary to be run with some privileges and can't reasonably use capabilities on it (for example, it's a lot of work to maintain a system with no set{u,g}id binaries on it and keep the software up-to-date on it as well).
Usually a shell is calling a binary to do the real work. So it should
even never ever needed to have some raised privileges for the shell.
That depends on what you mean by lazy. Scripts can't do core-dumps (there is no practical way to do a core-dump from a script and still be reasonably easy to debug), so they have to do something to provide data so developers can debug it. By having such things just dump a stacktrace, the developers are making it easier for stuff like ABRT and whatever Ubuntu uses for automated bug reporting to actually report things, which in turn makes handling bug reports more efficient (and a desire for efficiency is _not_ the same as being lazy).
Good example are all that userspace python tools that throw all thatThis is debatable. While the app should be giving a user friendly error
stack traces around the users ears (I don't know if that saying exists
in English...) instead of giving proper error messages.
message, getting a stack-trace and the exception name (and the exceptions
are usually sanely named) is still far better than just getting something
like 'Segmentation Fault', or just returning the error in the return code.
There is no added security from not providing the stack-trace because there
is no data leaked by it (it contains no information about the contents of
variables, and function names and included libraries can easily be seen by
just looking at the python program itself).
My pointing to that python problem is not about security then about how
lazy some developer are. And lazyness and security is nothing that can
go together.
The Message-ID header is supposed to be unique for the lifetime of the message (which effectively means almost forever for stuff on LKML, as it's archived). If you are getting multiple copies of a message with the same Message-ID header and different content in the message, then something is very broken, and if a MUA is reusing Message-ID's, then someone needs to file a bug against that MUA.By the way, guys, can we start to _not_ add every one in this discussion>from Cc. I still leave all Ccs intact with this mail but I would prefer
to the Cc? Currently I get every mail twice. One from the list and one
to just reply to the list. If anybody is not reading the list and wouldIf you're getting duplicates with the same Message-ID header, then your
like to get the mail, please insist.
mail-server is (arguably) broken.
I do not know any mailserver that cares about message-ids. Even more,
which one is the original one if they differ in body? (as they do for
example in this list.)
It it even more broken as some (surely broken) MUAs reuse message ids.
It should be delivering exactly one copy of a message with a given
Message-ID: header (this is really a de-facto standard,
I wouldn't say so.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature