DDub

Security isn't just about intrusion prevention, it is also about ensuring that the resource is available to the people who need it when they need it.

So, carry on with keeping bad actors off the network and ensuring that there is sufficient capacity and resilience in the network.

Sysadmins should concentrate on managing and securing the devices and not the network. This is advantageous with todays mobile workforce where users expect the same experience at the office, coffee shop or home.

actually I'd find running my ansible playbook much, much easier than transferring GB of disk image about. I maintain the playbook so that I can keep work laptop and personal laptop in sync. Although I am looking at Nixos as a possible replacement.

E2E encryption allows for snooping if there are 3 ends.

Is it not an implementation of double jeopardy?

Since the referendum new facts have come to light, that of what an exit deal would look like. New facts should allow for a new vote.

If remain had won, there would be no new facts so why would another vote be justified?

It's double jeopardy, there is a case for a fresh vote because new facts (May's deal/No Deal) are present. If there are new facts after this vote (for example a new A50 or similar) then there is the case for another one.

As an example, if we look at https://github.com/GoogleCloudPlatform/container-vm-guestboo... then there are a couple of things here that are IPv4 only. The first is that the application is only configured to listen on the IPv4 address family, app.run(host='0.0.0.0', port=80), on linux if that was changed to app.run(host='::', port=80) this the application would be able to receive both IPv4 and IPv6 requests (on windows the situation is different however) The second, and less important change, is that the redis connection is using 127.0.0.1, and if instead it was using "localhost" then that would resolve to the correct address family. This is less important as it is only relevant if there is no IPv4 on the server host, the first change would allow your app to accept IPv6 traffic.

Neither of these changes are required if there is a dual stack proxy or CDN that sits infront of your application, as they will most likely talk to your application over IPv4.

The other gotcha is if you try to interrogate clientIP for analytics, authorization, geo-ip etc, which may need a little more care.

It is slightly less secure than that as the password reset form has a notification mechanism built into it in that the next time you login you realise that you need to reset the password back to what you control, where the magic link does not have such a mechanism to let you know that a compromise has taken place. It is slight, and requires you to be paying attention.

It hasn't prevented a false alarm, which is why it hit the news... it's interesting that there is a lot of hang up on false negative (false alarm) and very little discussion about a false positive (hitting the test button instead of the real alarm)

I'm not scolding the ape, I'm scolding the organ grinder. When a drill deviates from the actions taken in an emergency it becomes a pantomime of little value.

I totally agree that the solution should leverage obviation to prevent human error in an emergency, that's what a drill is all about.

The point of a drill is to drill the procedure into people, so that when it is required the people are operating on autopilot without the need to actively think about the actions that they are performing. I would prefer to see the only two tapes next to the transmitter are the emergency tapes. If there is a drill then the drill setup will replace these tapes with the test tapes, and maybe place a corrupt tape there once in a while. With this fix, in an emergency situation it's suddenly someone has to remember to get the tape out of the cabinet (was it Alice's or Bob's cabinet that we put them in?) and use that rather than follow the process that has been rehearsed. This whole scenario whiffs of improper drill setup, not a failure of following the drill.

We're currently looking at moving our applications to k8s, and was wondering what deployment tools people are using? This week we are evaluating spinnaker, helm and bash wrappers for kubectl. There is concern over adding too many layers of abstraction and that KISS is the best approach.

But I don't want to die from a disease contracted from a dirty telephone!

Toronto; I usually strive to take the long way home because the most direct route is 2.5km

Why do you believe that they are opposing activities? I can make a journey by helicopter or by walking but the destination is still the same, however as I walk there someone might point me at a better one.

Sslh would give you this ability, if you're prepared to shim an extra program infront of your daemon; http://www.rutschle.net/tech/sslh.shtml

Unless you're mirroring across more than 2 drives, you have an AID setup.

It could be that the client device validates a checksum against the approved list at the store before installing? Haven't tested if this is the case, just spitballing a mechanism that would allow for the control without the hosting.

From what I understand it is the opposite, that because it was much easier to turn uranium byproducts into nuclear warheads it was the technology that won out over thorium.

Has anyone tried using these?

- https://github.com/gustaebel/passext (Chrome)

or

- https://github.com/jvenant/passff (firefox)

I use an alias to select when to, and not to, use host keys;

alias ssht='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

ssht floaty.vm # does not use host key checking

ssh my.bastion.host # validates host key

Really I ought to get SSHFP records populated when my vm's are created...

yes, but that doesn't make it not a dev problem.

Does this require the authentication cookie to be constant? If, for example, I issue a new cookie to the client every connection then this is mitigated?

Nope, it'll still rain