Pup Biru

so now you’re paying a private entity in this round about bullshit way for a service that isn’t actually the service you want but the service you want kinda is a side hustle for them in order to bring down their costs

insurance may be the way forward because the situation is so far beyond fucked it’s incredible

… but insurance shouldn’t be the answer

just make the insurance compliance stuff law and also make sure to add that if the rules aren’t followed you’re on your own

or undersea cables… wait… i’ve seen this movie on the news

guess we should abandon undersea cables in favour of starlink

saying Microsoft requires that you go out and obtain a signed certificate that proves your identity as a developer

clearly that’s not the case if this was exploitable… again, N++ has an auto update mechanism that they current use. if they used a microsoft signing key to sign a builds hash, this hijack would not be possible

thus they have an update mechanism that works around microsoft signing… how is irrelevant. that is the current state of the software

The update mechanism was successful hijacked because integrity checks and authentication checks were not properly in place

that part we definitely agree on

Notepad++ even said that they moved hosting providers after this happened to them

side note: doesn’t remotely solve the problem… software updates should be immune to this to start with. it’s a problem that the hosting provider was compromised, but honestly we’re talking about a state sponsored hack targeting other states: almost no hosting provider would include this in their risk assessment, let alone shared hosting providers

Can you point out an existing open source application that runs on Windows that only uses GPG signatures?

again, that’s irrelevant… the concept that we’re talking about isn’t even specific to GPG. signing a hash using a private key is basic crypto, and GPG is a specific out of the box implementation

if we remove microsoft signing as an option for whatever reason (which we have) then it’s still very possible, and very easy to implement signed updates into your own custom update mechanism

yes but as you yourself said

I think they want to, but Microsoft has made it expensive for open source developers who do this as a hobby and not as a job to sign their software. I know not too long ago, this particular dev was asking its users to install a root certificate on their PC so that they wouldn’t have to deal with Microsofts method of signing software, but that kind of backfired on them.

the part that we’re arguing against isn’t that a microsoft signing key would have fixed the problem, it’s

No, because you wouldn’t be able to execute the updated exe without a valid signature. You would essentially brick the install with that method, and probably upset Microsoft’s security software in the process.

this update mechanism already exists: it’s the reason the hijack was possible. whatever the technical process behind the scenes is irrelevant… that is how it currently works; it’s not a “what if”

adding signing into that existing process without any 3rd party involvement is both free, and very very easy

which is why this is a solved (for free) problem on linux

Windows and MacOS do not use that method to verify the authenticity of developer’s certificates.

completely irrelevant… software authenticity doesn’t have to be provided by your OS… this is an update mechanism that’s built into the software itself. a GPG signature like this would have prevented the hack

The update mechanism works fine, but you will not be able to execute the binary on a Windows or MacOS system

that’s what we’re saying: this update mechanism already exists, and seems to install unsigned software. that’s the entire point of this hack… the technical how it works is irrelevant

there are more ways to do signing than paying microsoft boat loads of money… just check a gpg sig file ffs (probably using detached signatures: again, it’s already built into existing tools and it’s a well-known, easily solved problem)

what’s irrelevant is the argument about how the auto update mechanism would work because it already exists

that’s all completely irrelevant…, there is already an update mechanism built into NPP: that’s the entire point of the attack… it’s this update mechanism that got hijacked

i’m certain all of us that haven’t bought into any of this will be fine and rich hedge funds won’t buy up property and stock from people with no options forced to sell at prices far less than what they paid

that’s correct. they want modern business video conferencing, which is a very different prospect than 1:1 messaging, or even personal group messaging. i’d argue that there are more of these available than there are business conferencing!

please don’t lump signal in with whatsapp 🤮 that kinda talk makes people think they’re largely the same (especially with the bullshit muddy water of whatsapp using signals encryption), and we have enough trouble trying to convince people to use secure alternatives already… between the open client, reproducible builds, and local key integrity they are truly not even remotely in the same league

these are different problems now though… sure you can make calls to existing VOIP endpoints and PSTN devices, but that’s not what they’re trying to implement: they’re trying to implement group video conferencing, which WebRTC was built for

i’ve already linked the docs that state that native windows containers exist. whether or not specific images exist is not relevant

WSL, Hyper-V and Windows Containers are all options

they have to be built specifically for windows (of course the kernels are different, so the binaries are going to be different) but you can run Windows native applications on Windows kernel with a different implementation of containers using the standard Docker CLI and interfaces

Cgroups are just 1 (by far the most common) implementation of the container backend

to use SIP, in a web browser, you need to use wrapper of some kind (probably WebRTC-based)… you can not directly use SIP in a web browser. given that web browsers are likely a hard requirement, it makes no sense to use 2 separate standards

SIP is the wrong choice for this project, and any greenfield project wishing to integrate web browsers with no hard requirement to support SIP devices

thankfully our southern states aren’t particularly humid: equator to our north, antarctic to our south

also 50C is roughly as hot as it gets on earth, and 0 is when things freeze (icy roads, snow, many things change) so even “round human temperature range” is a bullshit argument… 0C is much more useful for human temperature than 0F

yes but you need a server in the middle which is just a huge waste of resources when you could just use webrtc with basically no down side

it is not. meta controls the keys. that’s how they’re accessing the messages

the article says they can access any message, from any user, from any time period, even deleted, instantly

to make this a client-side exploit would mean that messages would need to be constantly sent in the clear (not targeted per user) for years now… and someone would have noticed that

we know meta holds the encryption keys: that’s a known fact… it’s much much easier for them to simply decrypt everything they store

simpler than that in most likelihood… meta is the key holder so login and password recovery is simpler (or at least that’s the excuse they give): you login, they send you your key, which they can also access (and decrypt your messages) whenever they like

this isn’t a client-side exploit. this is the fact that meta controls the encryption keys. the mention “widget”, but that’s not a widget on your device; they say it’s a widget on their workstation - whatever that means. i’m thinking it’s something akin to raising a ticket which triggers a workflow to remote install an app on a work device (a process common at large enterprises)

worker need only send a ‘task’ (i.e., request via Meta’s internal system) to a Meta engineer … the worker’s workstation will then have a new window or widget available that can pull up any WhatsApp user’s messages based on the user’s User ID number … Once the Meta worker has this access, they can read users’ messages by opening the widget; no separate decryption step is required

that’s incorrect. with whatsapp, your keys are stored on meta servers (the same as things like imessage). they can simply decrypt them whenever they like, just like being signed in as you. it’s completely invisible to your client