On 2015-11-09 12:23, Klaus Ethgen wrote:
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).-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512Am Mo den 9. Nov 2015 um 17:28 schrieb Austin S Hemmelgarn:Having some scripts in the process is definitively a nightmare to 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.It's still unavoidable in a number of cases. It's easy to re-write scripts 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 that stack traces around the users ears (I don't know if that saying exists in English...) instead of giving proper error messages.This is debatable. While the app should be giving a user friendly error 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 to the Cc? Currently I get every mail twice. One from the list and one>from Cc. I still leave all Ccs intact with this mail but I would preferto just reply to the list. If anybody is not reading the list and would like to get the mail, please insist.If you're getting duplicates with the same Message-ID header, then your 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.
smime.p7s
Description: S/MIME Cryptographic Signature
