1. 1

    Ahh, yes! I was going to try and make this with unicode box-drawing symbols but I hit a lack of diagonals of a certain style. Scale it up and use ascii characters! A simple solution.

    1. 2

      I was considering using the mathematical falling diagonal character, (‘⟋’, U+27CB) instead of the box drawings light diagonal, (‘╱’, U+2571), but it didn’t seem to make enough of a difference, to skip the extra line needed, so I decided to stick with the box drawing set.

    1. 14

      The demo is in Ruby, but in Python there’s also an easy way to do this. The zipfile built-in library accepts “file-like objects” in addition to directory paths, which expose a simple read/seek/write interface. With a class that implements range requests behind the scenes you can grab just the portion of the archive you need with no zip-specific code like the directory header bytes in the linked code.

      Here is a complete example I have used in production.

      1. 4

        I’ve implemented something similar, just to add seek support for fileobj backed by http. Maybe the urllib itself should support mapping seek to range request, so python developers don’t need to re-invent the wheel on their own.

        1. 4

          That is actually exceptionally clean:

          collection = zipfile.ZipFile(remote.RemoteFileObject(collection_url))
          

          All it needs is read/seek/tell as if it was a file, and then uses ranges underneath. Clever!

          1. 1

            Related: GDAL has a really neat virtual filesystem feature that allows you to prepend paths with one or more of /vsi*/ strings to read from remote URLs, peer inside archives, and talk to blob stores on various public cloud providers. Very handy in combination with new designs for cloud-optimized data formats that provide DB-like performance over dumb pipes.

          1. 13

            HTTP range requests are underused! They have a lot of untapped potential.

            FYI, you can express a range relative to EOF, so you don’t have to do a HEAD first to find the content-length.

            1. 4

              I actually thought it might be, but assumed, since it wasn’t an example in the Mozilla docs, that it wasn’t supported. Pretty relevant example to leave out!

              Should have read the RFC instead, which clearly have the format of the range specified:

              byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
              

              For curl it would just be -H "Range: bytes=<number>-" then.

              I feel like updating the post now!

              1. 10

                I just realised I was doubly wrong trying to figure this out. If I’d use the format above, I would still need to know the initial content-length, in order to count backwards from the EOF.

                Instead this is the one I was looking for:

                A client can request the last N bytes of the selected representation
                   using a suffix-byte-range-spec.
                
                     suffix-byte-range-spec = "-" suffix-length
                     suffix-length = 1*DIGIT
                

                And a corresponding curl header for only the last 100 bytes would be -H "Range: bytes=-100".

            1. 12

              Seems like a lot more hassle than just using Bitwarden, be it cloud, or self-hosted. especially on mobile. Plus even if not as secure, 2FA in bitwarden is great

              1. 5

                It’s more initial setup, but after that point depending upon your workflow it can be less hassle. In my case I’ve got it hooked up with fzf in my TWM so it’s more efficient than any proprietary UI could ever be. And long term there’s less hassle in using standard, multipurpose, open source tools like gpg and git.

                1. 5

                  Oh, I would be totally onboard, but since I use passwords and 2fa on mobile a lot, not having the autofill capabilities on that app the article linked is a bit of a hinderance, along with other niceties. For my usecases, bitwarden is open source enough to satisfy that.

                  But if I think about it, I can see the benefit in the simplicity of this workflow if you don’t need the features I depend on, or they extra app switching doesn’t bother you.

                  I tried pass a long time ago, probably around when it first came out and liked it, just mobile was always a sticking point, and syncing everything. I mean thats solved with stuff like Seafile, Nextcloud, dropbox, syncthing, rsync, etc. But it being built into what I am using is just a time saver.

                  I will also admit hat I am not as privacy-conscious as many are.

                  1. 11

                    Hi, Android Password Store maintainer here. The app does support Autofill, and does it rather well (even if I say so myself).

                    I assume the author is on a very old Android version which doesn’t have native Autofill capabilities. The mention of overlays probably is about System Alert Windows, which apps used pre-Android 8.0 to present Autofill UIs. The accessibility and clipboard backed implementation that was used before native Autofill is extremely buggy and unsafe, so we’ve opted to completely remove it in our development branch.

                    Another possibility is that they accidentally installed our legacy version that hasn’t been updated in a couple years, and was marked as archived on F-Droid but I presume stays accessible even today. Here’s the currently maintained version.

                    If neither of them are true /u/rhardih, please email me at aps@msfjarvis.dev with some info about your phone and Android version, and I’d love to sort this out :)

                    1. 4

                      Hi, this was totally a blunder on my part. I didn’t see it showing up in the Autofill menu next to LastPass and didn’t really think about it more than that, because I personally didn’t mind having to copy paste a bit.

                      I’m guessing it’s disabled by default, because it’s necessary to trigger the “Auto-fill service” system settings page when enabling, in order to choose Password Store as default.

                      I’m sorry for the misunderstanding. I’ve updated the post with a correction.

                      1. 3

                        Thanks for the prompt correction! We recommend users to enable Autofill from within the app since it allows us to present each currently installed browser’s Autofill support level upfront, so that users can adjust their expectations. This was mostly necessary back when Chromium-based browsers had absolutely terrible Autofill support, but is slightly less useful now that all the patches my co-maintainer has been pushing to Chromium have reached the stable channel with Chrome 89.

                      2. 2

                        Oh, cool, thank you for clarifying that and thank you for working on the app. I know it might not be for some, but it definitely solves a need for many, and I respect that and appreciate your efforts on the app.

                        I might check it out for work related stuff.

                        1. 2

                          Thanks a lot for your kind words :)

                  2. 2

                    It isnt. I host my password store on a git directory on my server and just use that to keep it updated on my phone and anything else. I also use rofi so having pass-otp and rofi-pass really makes it great on my desktop for example. The android app also just works with otp codes.

                    1. 1

                      I’m also in favour of a more seamless setup and am heading towards Bitwarden setup myself, albeit slowly.

                      Recently, I’ve been made aware of a 3rd-party command line client for Bitwarden - rbw - it lacks some basic functionality, i.e. one can only edit the pass{word,phrase}, but it’s quite usable otherwise.

                    1. 7

                      pass is great. I use it and I love it. It does, however, lack one key feature: the password filenames are not encrypted. This does leak information should a malicious actor access the password repo. pass-tomb and pass-code attempt to solve this, in different ways.

                      1. 2

                        Another interesting bit about the encrypted files is that the file size can tell you something about the passphrase length, assuming the file contains nothing but the passphrase.

                        Adding some extra data at the end of the file of random length is one way to work around it.

                        1. 2

                          I’ve previously had my .password-store in a Cryptomator vault and then put that on Dropbox for sync. This solves the filename problem. Given that I no longer put those files on a machine not in my control, it’s a fair enough tradeoff for now. Let’s hope I’m not wrong.