I think this highlights that while there are easy solutions to the problem the OP faced, they're difficult for a newcomer to discover. (I have been using Rust for a couple of months and I'd also have reached for serde and maybe serde_derive to solve the problem).
Hopefully this is something the Libz Blitz[0] will solve with their Rust Cookbook[1]. (You could almost but not quite arrive at as simple a solution from chapters 1 and 2).
I think the key part is "regardless of where they come from". For instance, Scotland has free tuition for the Scottish and other EU citizens, but not for citizens of England/Wales/NI or international students. (The fees for an English person are typically cheaper than other English universities, but still not to be sniffed at).
I am not sure about NI or Wales, but I imagine there's a similar situation.
The firmware signature ensures the updates are authentic, but not that they are fresh. An attacker could force devices to stay on an older authentic but vulnerable piece of software.
I think plain HTTP is not appropriate for most update schemes Interestingly, Google Omaha actually chose not to use TLS to ensure freshness, but has something custom.
Arguably someone adhering to the C++ Core Guidelines, using GSL and using the new static analysis tools (currently only in VS?) can be reasonably confident about choosing C++ for a new project in 2017.
Fantastic. Maybe hide the word "MSDN" somewhere in the page, just for search engines. Old habits die hard. :)
Slightly off-topic, but would it be possible to reinstate the code samples on the IIS Native Module section[0]? It seemed to go walkies about a year ago and no amount of "Is this page helpful?" feedback seems to get it back. It's quite important because there is little documentation elsewhere on the internet.
I do find the image of "fighting the borrow checker" is quite harmful to how people view Rust. As those links state, an important aspect of teaching Rust is educating people about why the borrow checker complains, so that they might adjust their mental model.
The new content looks a lot better, but I think it is a shame that this is not using the "MSDN" branding. One of the nicest things about Microsoft documentation is that I can add the term "MSDN" to any random web search and usually get the page I'm after.
Could you provide an example where the borrowing would cause issues for immutable data?
I'm still learning Rust, but I thought the fact that you could have as many immutable borrows as possible would limit what errors the borrow checker could throw at you.
It is not written in Python, it is written in RPython:
> So this is written in Python?
> It's actually written in RPython, the same language PyPy is written in. make build_with_jit will compile Pixie using the PyPy toolchain. After some time, it will produce an executable called pixie-vm. This executable is a full blown native interpreter with a JIT, GC, etc. So yes, the guts are written in RPython, just like the guts of most lisp interpreters are written in C. At runtime the only thing that is interpreted is the Pixie bytecode, that is until the JIT kicks in...
Opening it in a text editor is not sufficient. With clever use of 'sleep' you can even have the server return a malicious payload only if it thinks its getting immediately piped to sh[0].
If you're opening it in a browser to check, you've also got to worry that the server may be looking at curl's user agent to decide whether to serve up a malicious payload[1].
> Unikernels are specialised, single address space machine images constructed by using library operating systems. A developer selects, from a modular stack, the minimal set of libraries which correspond to the OS constructs required for their application to run. These libraries are then compiled with the application and configuration code to build sealed, fixed-purpose images (unikernels) which run directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.
I don't think it supports any browsers via plugin. You use a separate app to unlock your keychain, it places the relevant password on your clipboard and then it clears the clipboard 30s later. Very simple and therefore avoids a whole bunch of vulnerabilities other password managers (like LastPass) introduce by integrating with browser plugins.
> More likely because it's not available on-premise. Check into how many use HipChat instead, because it is.
Just one data-point, but: my employer went with HipChat because we needed an on-premise solution. (We were moving away from IRC because we needed persistent chat history for remote employees. Using IRC bouncers was considered too high of a barrier-to-entry, given we wanted non-technical employees to join the conversation too).
Does the government require this arbitrarily, or because that's the will of the people?
Here in the UK, we have Sunday trading laws which limit how long shops can be open on a Sunday. These are reasonably popular (but not unanimously) because they ensure that shop workers have some guaranteed time with their family.