HN user
Building Login.gov @USDS
if you thought it was safe
The problem is that companies introducing chemicals into a clothing product aren't required to show that they're safe, at least in the US. So considering the negatives only happens much later, if at all.
It's more about what happens when you toss your phone into the landfill after two years, and the mountain of dead electronics starts leeching toxins into the groundwater.
Login.gov | REMOTE or Washington, DC | Software Engineers, Site Reliability Engineers, Security Engineers | Full-Time | https://login.gov
Login.gov gives the public simple, secure access to multiple US government services through one verified account. We're working to fix online identity for US government services.
The Login.gov team operates like a startup within the government, working in the open as a distributed, agile team. The core product is open source, hosted in modern cloud infrastructure, and built for scale. Tens of millions of people have Login.gov accounts, and we aim to be the preferred entrypoint for all government digital services. Our users include people accessing benefits, applying for government jobs, serving in the military, and collecting funds awarded through grant programs.
Find us on Github: https://github.com/18F/identity-idp
The Login.gov project began as a collaboration between 18F and the U.S. Digital Service (USDS). Today it's part of the Technology Transformation Services (TTS). You'll join other software engineers delivering better public services through modern technology.
* Ruby Software Engineer: https://join.tts.gsa.gov/join/application-engineer/
* Site Reliability Engineer: https://join.tts.gsa.gov/join/devops-engineer/
* Security Engineer: https://join.tts.gsa.gov/join/security-ops-engineer/
The above postings open on a revolving basis. If they're not open, just email us at jobs@login.gov or joinTTS@gsa.gov, where we can answer questions and accept your application.
Feel free to reply on thread with any questions.
Login.gov | REMOTE or Washington, DC | Software Engineers, Site Reliability Engineers, Security Engineers | Full-Time | https://login.gov
Login.gov gives the public simple, secure access to multiple US government services through one verified account. We're working to fix online identity for US government services.
The Login.gov team operates like a startup within the government, working in the open as a distributed, agile team. The core product is open source, hosted in modern cloud infrastructure, and built for scale. Tens of millions of people have Login.gov accounts, and we aim to be the preferred entrypoint for all government digital services. Our users include people accessing benefits, applying for government jobs, serving in the military, and collecting funds awarded through grant programs.
Find us on Github: https://github.com/18F/identity-idp
The Login.gov project began as a collaboration between 18F and the U.S. Digital Service (USDS). Today it's part of the Technology Transformation Services (TTS). You'll join other software engineers delivering better public services through modern technology.
* Ruby Software Engineer: https://join.tts.gsa.gov/join/application-engineer/
* Site Reliability Engineer: https://join.tts.gsa.gov/join/devops-engineer/
* Security Engineer: https://join.tts.gsa.gov/join/security-ops-engineer/
The above postings open on a revolving basis. If they're not open, just email us at jobs@login.gov or joinTTS@gsa.gov, where we can answer questions and accept your application.
Feel free to reply on thread with any questions.
Login.gov | REMOTE or Washington, DC | Software Engineers, Site Reliability Engineers, Security Engineers | Full-Time | https://login.gov
Login.gov gives the public simple, secure access to multiple US government services through one verified account. We're working to fix online identity for US government services. The Login.gov team operates like a startup within the government, working in the open as a distributed, agile team. The core product is open source, hosted in modern cloud infrastructure, and built for scale. Tens of millions of people have Login.gov accounts, and we aim to be the preferred entrypoint for all government digital services. Our users include people accessing benefits, applying for government jobs, serving in the military, and collecting funds awarded through grant programs.
Find us on Github: https://github.com/18F/identity-idp
The Login.gov project began as a collaboration between 18F and the U.S. Digital Service (USDS). Today it's part of the Technology Transformation Services (TTS). You'll join other software engineers delivering better public services through modern technology.
* Ruby Software Engineer: https://join.tts.gsa.gov/join/application-engineer/
* Site Reliability Engineer: https://join.tts.gsa.gov/join/devops-engineer/
* Security Engineer: https://join.tts.gsa.gov/join/security-ops-engineer/
The above postings open on a revolving basis. If they're not open, just email us at jobs@login.gov or joinTTS@gsa.gov, where we can answer questions and accept your application.
Feel free to reply on thread with any questions.
Login.gov | REMOTE or Washington, DC | Software Engineers, Site Reliability Engineers, Security Engineers | Full-Time | https://login.gov Login.gov gives the public simple, secure access to multiple US government services through one verified account. We're working to fix online identity for US government services.
The Login.gov team operates like a startup within the government, working in the open as a distributed, agile team. The core product is open source, hosted in modern cloud infrastructure, and built for scale. Tens of millions of people have Login.gov accounts, and we aim to be the preferred entrypoint for all government digital services. Our users include people accessing benefits, applying for government jobs, serving in the military, and collecting funds awarded through grant programs.
Find us on Github: https://github.com/18F/identity-idp
The Login.gov project began as a collaboration between 18F and the U.S. Digital Service (USDS). Today it's part of the Technology Transformation Services (TTS). You'll join other software engineers delivering better public services through modern technology.
* Ruby Software Engineer: https://join.tts.gsa.gov/join/application-engineer/
* Site Reliability Engineer: https://join.tts.gsa.gov/join/devops-engineer/
* Security Engineer: https://join.tts.gsa.gov/join/security-ops-engineer/
The above postings open on a revolving basis. If they're not open, just email us at jobs@login.gov or joinTTS@gsa.gov, where we can answer questions and accept your application.
Feel free to reply on thread with any questions.
If there's not an obvious security contact at the agency, you can always report vulnerabilities to US-CERT, which has overall responsibility for connecting reporters to the right responders. https://www.us-cert.gov/
This links to the report form at https://www.kb.cert.org/vuls/govreport/
As with all vulnerability reporting, it's much more likely that someone will take action on your report if you can provide evidence or a reproducible proof of concept.
18F/TTS can sometimes direct reports to the right place, but it's really not their job to do so.
Login.gov | REMOTE or Washington, DC | Software Engineers, Site Reliability Engineers, Security Engineers | Full-Time | https://login.gov
Login.gov gives the public simple, secure access to multiple US government services through one verified account. We're working to fix online identity for US government services.
The Login.gov team operates like a startup within the government, working in the open as a distributed, agile team. The core product is open source, hosted in modern cloud infrastructure, and built for scale. Tens of millions of people have Login.gov accounts, and we aim to be the preferred entrypoint for all government digital services. Our users include people accessing benefits, applying for government jobs, serving in the military, and collecting funds awarded through grant programs.
Find us on Github: https://github.com/18F/identity-idp
The Login.gov project began as a collaboration between 18F and the U.S. Digital Service (USDS). Today it's part of the Technology Transformation Services (TTS). You'll join other software engineers delivering better public services through modern technology.
* Ruby Software Engineer: https://join.tts.gsa.gov/join/application-engineer/
* Site Reliability Engineer: https://join.tts.gsa.gov/join/devops-engineer/
* Security Engineer: https://join.tts.gsa.gov/join/security-ops-engineer/
The above postings open on a revolving basis. If they're not open, just email us at jobs@login.gov or joinTTS@gsa.gov, where we can answer questions and accept your application.
Feel free to reply on thread with any questions.
Login.gov | REMOTE or Washington, DC | Software Engineers, Site Reliability Engineers, Security Engineers | Full-Time | https://login.gov
Login.gov gives the public simple, secure access to multiple US government services through one verified account. We're working to fix online identity for US government services.
The Login.gov team operates like a startup within the government, working in the open as a distributed, agile team. The core product is open source, hosted in modern cloud infrastructure, and built for scale. Tens of millions of people have Login.gov accounts, and we aim to be the preferred entrypoint for all government digital services. Our users include people accessing benefits, applying for government jobs, serving in the military, and collecting funds awarded through grant programs.
Find us on Github: https://github.com/18F/identity-idp
The Login.gov project began as a collaboration between 18F and the U.S. Digital Service (USDS). Today it's part of the Technology Transformation Services (TTS). You'll join other software engineers delivering better public services through modern technology.
* Ruby Software Engineer: https://join.tts.gsa.gov/join/application-engineer/
* Site Reliability Engineer: https://join.tts.gsa.gov/join/devops-engineer/
* Security Engineer: https://join.tts.gsa.gov/join/security-ops-engineer/
If the above postings aren't open when you want to apply, email us at jobs@login.gov or joinTTS@gsa.gov.
Feel free to reply on thread with any questions.
This is a poor way to handle library upgrades that are guaranteed to break any existing compiled binaries.
Frustrating that my PR to create readline@7 was rejected. https://github.com/Homebrew/homebrew-core/pull/36782
I would at least like to see some mechanism to exclude a Formula from automatic gc of old versions besides brew pin. Libraries don't take up significant space, and they cause a world of hurt to delete out from under compiled binaries, so there is not a good argument for automatically deleting them.
The white "Access Denied" page is to help you empathize with Jony Ive, still trapped in a white room after all these years.
https://www.change.org/p/apple-free-jony-ive-from-his-white-...
It's interesting how your eye naturally groups the pentagons into the larger primitive unit, like the pinwheels of type 5.
Wolfram Alpha also has some things about tiling: http://www.wolframalpha.com/input/?i=pentagon+tiling http://www.wolframalpha.com/input/?i=pentagon+type+5+tiling
Enforcement of nameConstraints is inconsistent at best.
I experimented with name constraints a couple years ago for a private CA project, with the idea that I could restrict the private CA to issuing only names within a chosen subdomain.
I remember being able to enforce nameConstraints on the subjectAltName, but I was never able to get it to enforce anything on the subject Common Name. In theory new certificates should always have a critical subjectAltName extension, but this makes it worthless in practice.
It's also possible that my X.509 foo is not strong enough, or that I was testing with an older version of OpenSSL that doesn't implement it.
http://blog.codekills.net/2012/04/08/adventures-in-x509-the-...
It's interesting how Comcast's track record in complying with regulatory requirements from past deals may be a major factor here. I wonder if they would have been able to muscle this through had they been just a little bit less awful in the past.
Pretty interesting stuff. I do wonder how much internal collaboration there is on topics like HTML5 video & WebM. The benefits of owning end-to-end both browser and server for driving media codec development seem enormous.
It makes Google's decision to launch Chrome in 2008 much more of an obvious call.
Stripe checkout does use an iframe from checkout.stripe.com for the payment form.
I'd love to hear theories for what might have installed it. If anyone still has that certificate, it would be helpful to export it and email it to support@stripe.com.
We've worked around the issue for now by not using EV certificates, which isn't a great solution.
If this is anything like the issues we've seen at Stripe, the problem is probably an obsolete cross-signed root in your login keychain. It's caused by a certificate with CN="DigiCert High Assurance EV Root CA" but signed by some other authority rather than being self-signed. It's not clear to us how these are getting into people's login keychains, as they're not present on a fresh install.
Typically servers will present their certificate and intermediates but not the root, under the assumption that browsers must already have the root in their CA store. So for DigiCert that would probably be all the certs up to but not including "DigiCert High Assurance EV Root CA".
You can see the presented cert chain using `openssl s_client -showcerts ...` or the Certification Paths section of the Qualys SSL Labs Test: https://www.ssllabs.com/ssltest/analyze.html?d=github.com
Do you see an expired "DigiCert High Assurance EV Root CA" certificate in your login keychain? If so, delete it. If not, something weirder may be going on.
+1
I'd love to see your notes.
I found that when I was learning git there were two concepts that were crucial: understanding the staging area, and understanding the very basics of the DAG (not talking about tree objects, only spending just enough time to learn how to merge and rebase).
I have to say I was a little disappointed this tutorial didn't even mention the word staging, since it's pretty important to being able to use the interface.
Honestly I can't imagine how we ever used HipChat. The Linux client is abysmal, and the IRC/Jabber integration is also terrible.
Slack is really the best I've seen.
Not sure what the schedule looks like in general, but last night I waited ~10 minutes after the advisory watching the packages show up one by one. Still faster than any other source, of course.
We're working on it! :-)
There's an enormous difference between serializers that make any effort at all to be safe, and those like Ruby's YAML library, which make no effort. Python's YAML, for example, exposes a safe_load() method.
It's really criminally negligent that no such method exists in Ruby's YAML library.
While they're not great, chroots are much more powerful than most people give them credit for. The trouble comes when people think you can keep a root user contained in a chroot.
We're working on it. :-)
Along the same lines, are you doing anything special with munin to make it fast? We've had performance issues with the RRDs and graph generation that led us to pipe metrics to graphite with collectd.
Hilarious. I can't wait to see content relevant to my interests in my PD alerts.
It's pretty easy to run an instance for a few minutes while you rsync the whole thing wherever you want. We used AMIs mostly because we ran the CTF itself in AWS and didn't have a great place to store the images otherwise.
Not a bad idea, but how do you keep people from peeking at the passwords with root access on their own VM?
Not to worry, we spun up a new machine and didn't copy the ssh key from the old one.
2048 74:67:32:4a:04:b8:9f:05:b6:e8:29:43:26:12:75:11 /etc/ssh/ssh_host_rsa_key.pub is correct.