jim

joined 2 years ago
[–] jim 3 points 2 days ago

I almost spit out my coffee from this meme!

[–] jim 2 points 3 weeks ago (5 children)

I understand this change by Bitwarden, but I wish they gave us the option to turn this off or at least given us more time before forcing this on us.

There's a lot of comments talking about how this increases security, which is true. But it also increases the risk of account lockout. This is especially true in two scenarios: traveling and incapacitation.

Traveling - for those of us who travel frequently, we carry all of our belongings with us. This makes us particularly vulnerable to account lockouts. We can't securely store backup devices or documents in easily accessible locations. We can't easily rely on trusted friends or family because they are so far away. Also, internet accounts are more likely to lock us out anyway because we are logging in from a different country, which is suspicious behavior.

Incapacitation - god forbid, if there comes a time when we are permanently or temporarily incapacitation, it becomes important for our loved ones to access accounts. When we are in the hospital, it's important that our loved ones get access to our personal accounts. I personally have advanced directives and have worked with an estate lawyer to make sure that my Bitwarden account becomes available. I also have instructions for immediate trusted family on how to access my vault if I were ever in the hospital. With this short notice, I need to scramble to get all of that updated and provide a way for them to access the account without my 2FA devices.

The above scenarios are based off of my real experience. These are real and likely risks that I have to account for. Security is not just making sure that outside bad actors CANNOT gain access, but it also means that the right people CAN get access at the right time.


What am I going to do? I'm weighing my options.

  1. I believe the self-hosted version of Bitwarden does not require this. This comes with its own set of risks though.
  2. Pay for premium, which comes with lockout support - I need to see if this can take care of both use scenarios above.
  3. Turn on 2FA and memorize the recovery code. While viable, since I will only use the recovery code once, I'm likely to forget it.
  4. Change the email to a non-2FA email address, only used by Bitwarden, with a strong but easily memorable password. This email must allow access from foreign countries without lockout (gmail is out). I'm actually strongly considering this.
[–] jim 1 points 3 weeks ago (1 children)

This is being purposefully obtuse. Choosing to force users to memorize a recovery code increases the likelihood of lock outs.

There is a real risk of account lockout, especially for those of us who travel frequently. Lockouts are a significant risk when you need to carry all your belongings and devices.

There are also some of us who also think about what happens to us when we are incapacitated and a loved one needs access to our passwords. In a situation, it's important to balance security vs expediency to access critical information. This new policy disrupts that.

At the very least, I wish Bitwarden would have given us more time to force this policy. I have to scramble to make changes to my estate planning documents and get in contact with my lawyer to change my advanced healthcare directives.

[–] jim 1 points 1 month ago

One of my favorite achievements from a space agency. I hope we can return back to the Saturnian system with more landing probes!

[–] jim 3 points 1 month ago (5 children)

Then create one venv for everything

[–] jim 9 points 3 months ago

This is a classic piece, and I love the contradictions in the text. It encapsulates my feelings on good software and code that it almost becomes an art than a science.

[–] jim 3 points 4 months ago

What a wild ride! Can't believe it's been ten years.

[–] jim 7 points 4 months ago

PSA for Debian Testing users: read the wiki

https://wiki.debian.org/DebianTesting

Control-F security returns 18 results. This is well known and there's even instructions on how to get faster updates in testing if you want.

[–] jim 7 points 4 months ago

My thought was that a lawsuit is more expensive than arbitration, but settling a class action lawsuit is cheaper than thousands of arbitrations.

[–] jim 2 points 5 months ago

Took me a sec.

[–] jim 2 points 5 months ago

Thanks for sharing. We use all pytest-style tests using pytest fixtures. I'll keep my eyes open for memory issues when we test upgrading to python 3.12+.

Very helpful info!

[–] jim 2 points 5 months ago (2 children)

I'm most excited about the new REPL. I'm going to push for 3.13 upgrade as soon as we can (hipefully early next year). I've messed around with rc1 and the REPL is great.

Do you know why pytest was taking up so much RAM? We are also on 3.11 and I'm probably going to wait until 3.13 is useable for us.

 

Here's a hypothetical scenario at a company: We have 2 repos that builds and deploys code as tools and libraries for other apps at the company. Let's call this lib1 and lib2.

There's a third repo, let's call it app, that is application code that depends on lib1 and lib2.

The hard part right now is keeping track of which version of lib1 and lib2 are packaged for app at any point in time.

I'd like to know at a glance, say 1 month ago, what versions of app is deployed and what version of lib1 and lib2 they were using. Ideally, I'm looking for a software solution that would be agnostic to any CI/CD build system, and doubly ideally, an open source one. Maybe a simple web service you call with some metadata, and it displays it in a nice UI.

Right now, we accomplish this by looking at logs, git commit history, and stick things together. I know I can build a custom solution pretty easily, but I'm looking for something more out-of-the-box.

 
 

One of the coolest projects I've seen: a lisp that is embedded into Python. Hy compiles to Python AST so it's (almost) fully interoperable with Python (some notes about it here).

-1
submitted 2 years ago by jim to c/programming
 

Trying to make web applications federated is a popular effort. Examples include things like the “fediverse”, as well as various other efforts, like attempts to make distributed software forges, and so on. However, all of these efforts suffer from a problem which is fundamental in building federated applications built on top of the web platform.

The problem is fundamentally this: when building an application on top of the web platform, an HTTP URL inherently couples an application and a resource.

5
submitted 2 years ago* (last edited 2 years ago) by jim to c/meta
 

The sidebar for our instance has a broken link for programming.dev - it links to https://programming.dev/programming.dev

 

It was a great app! Been a user for as long as I remember using reddit on my phone.

Thanks @[email protected] I appreciate all your hard work over the years.

28
submitted 2 years ago by jim to c/python
 

I generally don't like "listicles", especially ones that try to make you feel bad by suggesting that you "need" these skills as a senior engineer.

However, I do find this list valuable because it serves as a self-reflection tool.

Here are some areas I am pretty weak in:

  • How to write a design doc, take feedback, and drive it to resolution, in a reasonable period of time
  • How to convince management that they need to invest in a non-trivial technical project
  • How to repeat yourself enough that people start to listen

Anything here resonate with y'all?

view more: next ›