jabot

... and your point is?

EDIT: more recent bugs:

https://tls.mbed.org/security

These bugs include double-free and use-after-free - which are not covered by the original analysis, right?

That's different from directly writing C...

In the context of the article we're talking about a highly specialized office environment, where bios/live boot environments etc. do not happen often. There, a software solution is useful and cheap.

In the more general case, and for those people that do not mind carrying their own keyboard everywhere, you are right. Especially since a keyboard that expensive probably lasts for a long enough time...

https://superuser.com/questions/413384/how-to-remap-control-...

However, 350$ seems like a lot of money for a problem that should really be solvable at no cost in software...

However, I remember trying to map capslock to control on windows a few years back. It involved becoming an administrator and entering an opaque hexadecimal key into the registry.

Simply popping off the key is probably easier.

Oh, on linux it boils down to "setxkbmap -option ctrl:nocaps", which doesn't require root...

m(

I think that is a good thing, kudos to them.

The thing that would make me really happy is a play-framework-free build on f-droid. I'm not holding my breath, though...

> Marlinspike reiterated that the whole point of end-to-end encryption is that users no longer need to trust anyone if the protocol works — and Signal does.

But it depended on the google play framework - and I don't trust google. So where does that leave me?

EDIT:

To reiterate: As far as I can tell Signal itself is secure enough. However, the most secure chat app is insecure if it is run on an insecure operating system.

Now, I don't want to start a discussion about android security. But:

- The update situation is quite bad, leaving (for example) my phone with exploitable bluetooth

- Google itself ... could at least be coerced by a state actor into compromising anyone's privacy

With those two facts given, the practical difference between signal and telegram seems... less relevant.

[1]: Look at the "conversations" app. Yes, it is for XMPP, which is old and uncool - but it (a) doesn't use the play framework either and (b) uses very little battery on my phone, despite holding an open connection most of the time. That IMO proves that depending on the play framework is unnecessary in this case.

I wonder when we are going to see it on f-droid.

They show an example micro payment system as browser plugin, where you pay for reading articles.

I am excited at the prospect of paying for articles without spying adware and coin-mining javascript.

Back to your point: Even in the EU paypal has still users, because it is still easier to use than SEPA - transactions.

One use case that they have in their demo is micro payments to access web sites: https://demo.taler.net/en/

However, as far as i can see there is no bank offering a backend yet. Hopefully that will change soon.

It would have been great if the taler system had been usable at SHA 2017. We had to use weird, cheap and easily falsifiable plastic coins at the food court. Using taler instead would have been a really great tech demo...

Think about time spent counting, ensuring that there are no falsified notes, bringing excess notes to the bank and making sure there is change, etc.

I think it is quite feasible to create an electronic payment system that has comparable overhead.

Consider that there are existing electronic payment systems, e.g. electronic cash in europe, that already work and are quite secure (being smartcard-based)

The demo was nice, even though i did not understand any of the crypto. Although, to be fair, i didn't even try :-)

One important take away for me was that this project aims to replace paypal, not bitcoin. Its target is to establish an open source payment infrastructure that is better than paying with credit cards, paypal, etc...

As opposed to brexit representing a "will to shoot your own foot"?

> The EU is unrepresentative, unproductive, and unaccountable. Nobody needs any more reverence for it. The EU is the worst French idea the Germans ever took to.

I think you fell for brexit propaganda... The EU bodies are either elected directly or sent by the member state gouvernments, not some unaccountable hereditary monarch.

> Germany is today a country where foreign journalists are chased through the street by communist activists, and where you need a license to post a video on YouTube.

You're nitpicking. Or would it be fair for me to say that GB is not safe for young girls (rotherham...)?

> Britons could stand to learn from Germany's mistakes and be more honest with themselves before it's too late for anyone to be honest with anyone.

I agree completely. How about a little less mass surveillance for a start?

That's uncalled for, man...

> Of course there are still use cases where Algol derived languages are still unsafe, however those use cases are a tiny portion of what happens in C land.

On that I agree - there are many problems we wouldn't have if we were using, say, pascal or modula.

> Also you don't seem to know much about Ada given your GC remark, but here is some learning.

I'm sorry, I don't have time to watch that. However, I know that ADA has either GC or manual memory management (with the deallocation method explicitly marked as unsafe). Thus, as far as i know, constructing "use-after-free" in Ada is possible - which is undefined behavior (and that was my point).

- ADA requires garbage collection

- Modula-2 and Object pascal have manual memory management, i.e.: "new" and "delete" - together with double-free, use-after-free, and dangling pointers...

I agree that C is by far worse, but please recognize that at least some of the undefined behavior problems are really hard to solve.

EDIT: Oh, and we haven't started talking about multi threading yet, have we?

And yes, if you want to allow manual allocation of objects and setting pointers to arbitrary objects, then your two choices are: 1) garbage collection 2) undefined behavior (use-after-free, double-free, dangling pointers, etc.)

There is nothing in there about laptops and/or flights...

Citation needed on that one.

Also... Adding a timer to a laptop battery bomb so that it goes off in the storage department is... probably very easy?

    int f(int x, int y) {
       return x << y;
    }

This is caused by two facts:

a) The arithmetic operation should be compiled to a hardware shift instruction where possible

b) Different architectures do different things when shifting by an amount bigger than the word size:

- on ARM, the "y" operand is evaluated mod 32

- on x86, if y is greater than 31, the result is 0

Actually, pushing function arguments right-to-left means that the first argument ends up on top of the stack - and that makes vararg-style functions possible.

Think about it - a called vararg method must be able find the fixed arguments to figure out how many arguments it actually gets.

How many projects are _started_ in a language, and how many _die_?

Given p.e. Java - It may seem that there is a huge flow to go. However, if there are enough new projects started in java, then the number of java projects might still rise faster than the number of go projects.

Are you opposed to dynamically linked libraries in general? Or do you simply oppose using them for name resolution? And how would you propose implementing NIS, LDAP/Kerberos, etc. without them (and without recompiling the libc itself)?

> For example, Linux still does not have a sane DNS resolver interface that is useful without GNU-C library. With move to containers that lead to many issues like inability to resolve link-local names etc.

Valid criticism. But that's not the GNU peoples' fault, IMHO - I mean, they have a working libc, it's not their fault that containers don't work with other libcs. (Or do i misunderstand you?)

Thanks for that :-)

I think asprintf is useful - it replaces an ugly "malloc-realloc-snprintf-loop"...

On exposing non-portable functions/features:

  - OpenBSD does it (pledge)

  - Freebsd/NetBSD do it (kqueue)

  - ... I'm certain other systems do too

> Maybe in a blog post someday.

I would like to read that. :-)

[edit: formatting...]

> GNU software is also often very bloated and overengineered, and often found in critical places like glibc.

My memory is rusty - aren't those features "protected" against accidental usage, with something like "#define GNU_SOURCE" needed before you include the headers? Or is that protection insufficient?

> Their coding styles are highly questionable and I disagree with a lot of their design decisions.

On the coding styles I agree. On the design decisions... I realize that this is a big and hard question (and that answering it probably amounts to another blog post) but could you please explain that, maybe with an example?

I thought the author also implied that GNU was technologically inferior and/or problematic. That would interest me...

However I thought that "blight" implies some actual technological inferiority. If there is some, I would like to know more about that.