Recently posted comments

...of something else

Those that have bought the agri-business kool-aid. I remember someone on Groklaw (that dates it) saying that his seed, that his family had kept and re-sown for generations, yielded maybe 20% more than his neighbours buying in high-yield seed. Thing is, the commercial seed does well in the conditions it's bred. It doesn't necessarily do well in different conditions elsewhere, while seed that's been kept and re-sown adapts to the local conditions.

Cheers,
Wol

We both know that "can" actually means "will ignore completely" 99.7% of the time.

The whole point of a library is to be embedded inside some larger process. When you create a process, it's not by running a library, it's by running a program. So it should be the program that decides when that process ends. The lifecycle of that process is none of the library's business, and the library should not do anything to interfere with it. It is entirely inappropriate for a library to unilaterally pull the rug out from under the entire process by early terminating it.

If the library has entered a state where it can no longer perform useful work, then it can just tell the application that. It can return a special "fatal" error response, and if it's completely hosed, then it could set a flag so that all other library calls immediately return the same fatal error. This flag would only be cleared when the problematic state has been fixed (eg. by a special function call which re-inits the entire library, clearing out all its internal state).

For example, the program might be using the library for some optional functionality. In this case, the program could be happy to continue on without the library, using some fallback/alternate instead. Only the program can make that decision, and the library should not even try to second-guess it.

It is completely reasonable for developers to expect that libraries won't go and call exit(), or kill(getpid(), SIGKILL), or similar. Just like I expect random root daemons won't go and reboot my whole system just because they've encountered some problem that they consider severe.

Whatever happened to the "catch low, handle high" error handling philosophy? Libraries have no knowledge of the surrounding context in which they are running - ie, the rest of the program. But this is precisely why they should not be handling such errors, only reporting them. The caller can bubble the error up to a level that is best placed to handle it appropriately.

1. Output a warning message to stderr that the un-versioned python command is strongly deprecated.
2. Scan the script to identify any hints as to which python version is required. For example, a print statement without brackets requires python 2, an f-string requires python 3, any type hint strongly implies python 3, ...
3. Output another warning saying what it's going to try next
4. Dispatch the script to python3, unless python2 was clearly required, in which case...
5. Dispatch to python2 if it exists on the system or explain the problem if it does not.

This will work most of the time, and the warning messages (whether or not it does work) ought to nag the script maintainers to fix their shebangs.

If invoked without a script (interactive), tell the user to choose between python2 and python3 and quit.
This isn't something that has to be perfect. A 90% solution is better than a 0% non-solution.

Fixing banglines is trivial, only the diagnostic-to-bugreport-to-new-package bureaucracy takes a bit of time. After so many years, I'd expect that most packaged python2-only scripts have been fixed, and only in-house packages remain. It shouldn't be that hard to write a script to find and report/fix such scripts.

I'm unsympathetic to the "it'll break my setup" argument when the fix is so simple and has been needed for so many years. The python community has been doing extra work to support a legacy version, waiting for people to switch for surprisingly many years. It's time to give them a rest.

This is pretty much THE worst possible solution.

Besides that upcalls are also slow, and hence had to be replaced in many cases with something more performant anyway (think: hotplug upcalls, cgroup agent upcalls, and that stuff). Or think of core_pattern handling: let's say you make firefox crash, now the kernel does an upcall for processing that coredump, which is quite often very CPU and IO sensitive, to the point of slowing down the system drastically. But of course, since the thing runs as upcall it will be outside of the resource mgmt of the rest of the system and unrestricted in lifecycle and resoruce usage, unless it decides to manage itself. In systemd we thus had to replace the core_pattern by a binary that takes the stdin pipe and sends it to a properly managed daemon via AF_UNIX fd passing, and exits quickly, to minimize the unmanaged codepaths. This way the bulk of the core dump processing can be nicely sandboxed, lifecycled and resource managed. But yuck! Why is that even necessary? Why can the kernel just notify userspace in a friendly way without forking of nutty stub processes?

Please, let's just forget about upcalls: provide proper APIs right from the beginning that userspace can subscribe to and then handle without a process being spawned.

(or at least add a generic upcall logic that allows userspace to handle the upcalls instead of the kernel doing the fork()+execve() on its own)

Seriously, fuck upcalls!

Lennart

I agree that it's a disservice to have no unversioned python available and think that the stance to never point the symlink away from python2 quite backwards.

IMO these are two separate questions, and I don't see that acknowledged in the PEP. This is because the implications of the default behaviour are different in each case. When typing 'python' at the command line, you're immediately greeted with the version number that's running, and you can just <Ctrl-D> if it's not the one you expected. Scripts, on the other hand, can be executed non-interactively in the background and might thus break people's setups in non-obvious ways if they fail.

So it seems to me that the sensible behavior is to make python point to the latest version of python when invoked on the command line, but python in shebang lines should continue to point to python2 forever. And I say this as an Arch Linux user, whose python has pointed to python3 since the beginning, and I'm perfectly happy with this---but acknowledge that it's untenable for the more mainstream distros.

That is an interesting new twist in the display-password-or-display-dots question. Accessing graphics memory is probably more of a threat than shoulder surfing these days. (I would be interested to know if it really is a realistic threat, as in worth the effort for an attacker.) A flag marking a graphics surface as sensitive or something on those lines might help.

About printing the default key on separate paper, sure it has both advantages and drawbacks.

Advantage: visitors with temporary physical access cannot reflash the device unnoticed
Disadvantage: the paper may be lost

In case that default password is just used for flashing firmware, with a separate password for management of the device (the latter would be set to empty on factory reset), it seems it would be okay. The former use case is rare enough for not causing the vendor much extra work, or customers losing much for being unable to to that (Anyone wanting to mess with the firmware should make sure to obtain and not lose the password). The latter case would just be protected against by making the device lose the wifi pw on factory reset, so it won't go unnoticed.

Also I believe that obtaining a PK certificate from the vendor on request would not protect from the "visitor attack" scenario, as the visitor might just do that for his own pubkey. How would the vendor determine whether the request comes from the rightful owner, when the only proof is physical access?

> The problem is what happens when python2 it's no more and python no longer points anywher
Once this happens (maybe around 2034) then these scripts can just fail.

As already said, applications can use prctl() if too sensitive to core-dump, and that covers all cases not just abort () triggers

But why? There's no reason whatsoever for this change other than vanity. Just stick with python2 and python3 - easy and unambiguous.

Not if all the libraries jump ship. A ton have already pledged to do so in 2020: https://python3statement.org/

(Moreover, if a given library has *not* published plans to transition to Python 3 in the very near future, I would tend to wonder whether it is actually receiving upstream support in the first place. I'm sure some are, but there's a lot of bit rot out there.)

Even if the secret is protected with both MADV_DONTDUMP and mlock() the library may copy that memory. That copying might not be unreasonable -- to access data in modern CPUs is to copy it, at the very least into CPU caches and registers.

We saw the same thing recently with password databases, where graphics libraries retained the contents of previously-displayed text and so passwords were still in RAM even if the password database had erased its own storage. In turn those graphics libraries may feel that free()ing data means it has passed from their responsibility.

So fuck you Python developers. You're creating needless work for everybody to reassure your sense of self-importance ("See! We did it! Py3 is now mandatory!").

For a lot of devices having the default PW printed onto the device itself is viable...

There's nothing "controversial" here, just lack of understanding.

I guess that's okay for ISP-provided routers - the customer has a contract with the ISP, so customer support has enough information to verify the identity of the caller then tell them the original password. And the ISP already provides customer support in the user's language, and is being paid like $50/month, so it's relatively cheap to deal with the occasional lost password.

But that solution doesn't scale to many IoT devices. Maybe you're buying the device for $10 from a small Chinese manufacturer. They can't afford to provide that level of individual customer support. And you're definitely going to lose track of all these password sheets if you have one per lightbulb. The manufacturer might still care about security, so they'd like a cleverer technical solution that provides a decent level of security without those support costs.

That part would be https://lwn.net/Articles/464276/

The real solution, of course, is federation. But good luck getting the big players to open their silos.

"Right now the emergency messages are set apart from the non-emergency messages using '\n'. There have been requests that some special markers could be specifiable to make it easier for parsers."

My reasoning about having the first is that it protects dumb users (who never change the password) from fun guys coming to visit, who want to reflash the firmware unnoticed. It is simply prevented by the owner storing the sheet with the preconfigured pw somewhere unknown to the attacker (which is likely).

About pubkey, it should be enough for the new owner to change the password, no? Not pubkey needed:

- previous owner provides current password, or just the vendor preconfigured-one (the latter would need a factory reset)
- new owner types in current password, which allows him to set his own one

Multiple entries with the same timestamp are treated just fine (de-duped), the problem is timestamps going backwards.

I guess I'll have to add more complicated logic to detect unsynchronized messages.

In any case, if I were you I'd add my own timestamp (time when the message was read from the kernel).

But now I'm unsure why we need to track nesting_count at all, and clear mmiowb_pending at the start of an unnested spinlock. Surely nesting_count could only be 0 if either the CPU has never had a spinlock or it released a spinlock since it last did mmio?

If it's acceptable to reset the device back to a blank factory-default state prior to the sale (or after, assuming physical access is sufficient proof of ownership) then the new owner can program in their own secret when they receive the device. If not, the existing owner needs to transfer control to the new owner prior to the sale, and doing that without letting the existing owner know the new owner's secret requires a public-key authentication system. Reasons not to perform a factory reset include deterring theft or tampering while the device is in transit and/or wanting to preserve any data already on the device.

They could just do the same as router vendors currently do with Wifi-Passwords.

- store a random (per-device) key/password in the device memory
- print the key/password on a sheet of paper which is delived to the customer together with the device.

Which I like to paraphrase as, "If all you have is Excel, everything looks like a spreadsheet."

As far as I can tell, Subsurface build target set is very similar to OpenOrienteering Mapper one.

https://github.com/OpenOrienteering/mapper/releases
https://github.com/OpenOrienteering/mapper/wiki/Target-sy...

Sounds terribly like web browsers of today. Not sure that replacing web apps with git apps would be such a bad thing. :)

> 5. Better to make a few users love you than a lot ambivalent.
>
> Ideally you want to make large numbers of users love you, but you
> can't expect to hit that right away. Initially you have to choose
> between satisfying all the needs of a subset of potential users,
> or satisfying a subset of the needs of all potential users. Take
> the first. It's easier to expand userwise than
> satisfactionwise. And perhaps more importantly, it's harder to
> lie to yourself. If you think you're 85% of the way to a great
> product, how do you know it's not 70%? Or 10%? Whereas it's easy
> to know how many users you have.

http://www.paulgraham.com/13sentences.html

The readahead system call does that.

In this passage :

"When CONFIG_HIGHMEM is not defined, is_highmem_idx() (and PageHighMem() derived from it) return zero unconditionally. Any code within functions that follows the "if (PageHighMem(page))" pattern will be automatically optimized away as dead code.

But this works only because is_highmem_idx() is marked static; ".

Why this works only for static functions ? Static keyword implies only about the internal linkage right?

Thanks

European legislation on the other hand, as someone else pointed out, is more interested in outcomes. So you should legislate that "businesses must be able to demonstrate robust, working procedures for dealing with the bugs in the code in their products". In other words, if your reaction to a bug report is to sweep it under the carpet, or if it's a serious bug to run around like a headless chicken, then you're in breach of the legislation and liable for the consequences.

If, on the other hand, you have a mechanism for creating, and rolling out, bugfixes to your products to deal with problems then it's much easier to show compliance with the legislation - you just point to your security team and say "watch them triage bugs, create fixes, and roll them out". The system is there, it can be watched in action, and while it may not (indeed, pretty definitely won't) fix all the problems it will result in far fewer of them.

Cheers,
Wol

Most likely not at all. There's so much superstition among audiophiles; this used to entertain me, but it got boring after a while.

A low-latency kernel can help, but this is very very unlikely. It will only help if the audio chip's buffer drains empty ("xrun") before the player software can refill it, because the CPU is hogged by other processes. A properly configured real-time kernel will try harder to give the player software a share of the CPU before the buffer drains empty.

An xrun is a very audible thing. If you don't hear it, it doesn't happen, and if it doesn't happen, a real-time kernel has no effect at all. Same goes for any other choice made by this distribution.

Of course, it's a good thing to be "free of unnecessary daemons and services", but that has nothing to do with audio quality.

There are choice which can affect audio quality, for example if the player software (for some reason) decides to resample, or convert to a different sample format. There are ways to avoid it or at least reduce the degradation.

As MPD developer (the player software chosen by Audiophile Linux), I spent a lot of time trying to avoid lossy audio format conversions during playback whenever possible. Even though I'm confident that many such optimizations cannot be possibly distinguished by even the best human ears on earth.

The actual reaper process is very simple: it just calls wait() in a loop. The complicated parts of something like systemd (or even sysvinit) are the parts that set up and run all the services, not the part that reaps processes.

Then almost certainly. There's a "journalistic, artistic, or literary exception" (Article 85) but it seems like that could be a legal nightmare of the "just cheaper to delete your account" kind.

I've got a more tangible harm of not doing that for you: the same people who are unlikely to buy safe food are also unlikely to voluntarily buy health insurance, therefore (when the unsafe food bites them or the unsafe drugs don't cure their disease) they end up as non-paying customers of the hospital's ER, thus forcing increased healthcare costs on the rest of us.

This is not hypothetical. In countries with mandatory insurance, going to a hospital costs an order of magnitude less than in the US.

Not true. *All else being equal*, safe food and medicine are obviously preferable to unsafe food and medicine. However, that condition almost never holds. Safe food and medicine cost more—and given the choice, quite a few people would choose slightly more risky products over safe ones with higher prices. The FDA makes people safer (by some metrics) by forcing them to either pay the higher price or go without, thus trading one highly visible form of harm for another, more subtle kind.