> and autotype

I would go crazy w/o autotype. The way the IT dorks were forced by management to set up 'SSO' via an external provider at work, you have to enter the same information at least 3 times a day. 'SSO' for management means 'sign into each of our tools each single day'. Muh, no work done equals better security!

I'm in info sec and I agree with you. cyberArk weekly password rotation, no ability to save passwords in Edge, no ability to install a password manager.

Guess who keeps their password saved in notepad, all but three characters?

Usually SSO means that you have to login just once to access all of your accounts. If it requires you to login multiple times a day then something is not configured correctly.

Well... at my current employer, we have 3 "SSO" providers.

By that, I mean three different Okta logins, and logging in to any of them will log you out of the other two. If I want to do anything, it means I need to log in again because it is unlikely that I am logged in to the right account.

Yes, I need all 3 multiple times daily. There is no logic about which one I need for which system.

IT knows this is not how it is supposed to be, but they assure us that this is a temporary situation. I guess 1.5 Years is still temporary.

If you can use Firefox, it allows you to create multiple "containers", each with its own set of cookies and other state. You can create a separate container for each Okta login, then you can be logged into all three accounts simultaneously.

Also you can create a separate browser profile for each account. This works with all browsers but is less convenient, because it forces you to have a separate browser window for each profile, and also you need to enter all preferences for each profile separately.

Can someone make a security related case for disabling autotype?

Yeah that makes no sense, if anything I'd keep autotype and prevent copy password

"If hit by mistake it might autotype in a window that is not at a login prompt, but maybe on a chat session and broadcast the user's password"

It's horseshit, but it's an argument

lets see what it does here...

NikkiA

edit: well, I guess it didn't broadcast the password, but it probably would have done on a real chat window that accepted multiple lines of input

That's actually reasonable. I use keepassxc, and I have messed the autotype many times. But I mean, that is not an argument for disabling the feature.

I'd assume it would only put the password in a type="password" input, not a random text box.

No, autotype does what it says, it simulates typing keys without looking at the screen

If it's turned off by default, then please explain the drama. This simple statement makes this drama look like a storm in the proverbial teacup.

If I have both enabled in my install, which I specifically chose to, then upgrading the package locks me out of my database, because those features are not compiled.

Jeez, then you simply install the keepassxc-full package and move on. It's not like you store your sudo password in keepass database, too.

but that is part of the problem: this isn't clearly communicated to the end user in the future or present.

Current users will have their install broken and need to google to figure out what is going on.

Future users will install `keepassxc` thinking it would be actually KeePassXC before potentially realizing its a minimal version.

Personally I think splitting it into `keepassxc-full` and `keepassc-minimal` would be better since it moves the choice to the user instead of implying the contents.

How more clearly do you expect it to be communicated?

apt shows the NEWS file during update when there's a change. If it doesn't (ie. user set it up to blindly do the upgrade), you can still check the news file or .debian.changelog.gz file afterwards.

And note that this happened in testing/sid channel, where breakage is supposed to be happen. When this change shipped in the new major Debian stable release in a few years, it'll surely be clearly written in the release notes.

What else do you expect, SMS notification? :P

If a user haven't seen the above he for sure won't see an announcement in a crowded debian-whatever-announce mailing list he isn't subscribed to or an obscure blog post posted somewhere he doesn't follow.

I've almost never needed to read those news to keep the system working as I want it to. That's the thing.

How would you know in the first place

apt shows the NEWS file during update when there's a change.

If it doesn't (ie. you set it up to blindly do the upgrade), you can still check the news file or .debian.changelog.gz file afterwards.

Lastly, when it's shipped in the new major Debian stable release in a few years, it'll surely be noted in the release notes.

>How anyone could see a smaller attack surface as a bad thing on HN baffles the mind.

Because in the real world, with real users, you must balance security and friction. If you have too much friction, users look for workarounds and your theoretical security increase becomes a real world security decrease.

For a real world example of this phenomenon, see forced arbitrary password changes (which are now universally discouraged). They are theoretically more secure, but study after study has proven that, in the real world, forced arbitrary password changes reduce organization-wide security.

Security requires a holistic approach. Users and their behaviors are part of that. Looking only at attack surface is a sure-fire way to make your users work against your security policies rather than with.

Why does everyone keep using this word "plugins"? Quoting the developer:

> You fundamentally misunderstand our program when you use the word plugin. These are built in features, not plugins. The features can be enabled as desired by the user and they come disabled by default. This change to not compile and ship these features in the base keepassxc package does nothing besides create angry (or confused) users.

> How anyone could see a smaller attack surface as a bad thing on HN baffles the mind.

Because if it removes features many (perhaps even most) people use then that makes it less useful. And potentially insecure as people will stop using KeePassXC and replace it with "passw0rd123", because "I really need to get this done now, and not fuck about with KeePassXC not working". Is there even a message? Or any indication in the UI what's going on? I don't think there is.

Here's what should have happened if you really think that "keepassxc" package should install a minimal version: contact maintainers of KeePassXC, discuss best way to do this, maybe allow them some time to create better UX on this. Maybe create a PR or two. And then change your package. That Debian bug was 4 years old – it could have waited a month or two more.

You're also far too hung up on the word "plugin". That word has tons of meanings, and the original meaning of "something optional I can add (plug in) later on" doesn't really apply here.

Compile-time flags are by definition not plugins. All optional features were removed indiscriminately.

Your conflating PLUG IN technical term with PLUG IN from a users perspective.

No one was really friends with tom on myspace.