drwetter
Interested in maintaining the snap?
Hey there! First of all, I love the project. It's been very useful to me!
I've been maintaining a snap for it for a few years now, and it has a few hundred steady users. I'm happy to continue maintaining it, but I'm sad to say that I totally missed the jump to v3.0 and only just now pushed that out, which leads me to ask: would you prefer to maintain it yourself? It's a single YAML file and there's a github integration to build a new snap on pushes, so it's not a large maintenance burden and I'd be happy to help you get things set up.
Again, no pressure. Let me know what you think.
Hi Kyle!
thanks for reaching out.
TL;DR: can't tell for sure . Depends on the effort maintaining and my learning curve. Never used snaps myself, happy to learn though. I looked at your YAML file, seems pretty straight forward.
Can the snapfile be located in this repo and how to implement the hooks for the integration?
Cheers/thx, Dirk
Hi, snap would be awesome. I just ran into a situation where I want to export a html report but only have a very odd OpenSSL version available. Tried docker, which did not work (html will be generated inside the container and then discarded).
Sadly the snap from @kyrofa also does not solve this, as testssl --html domain just throws alot of Permission denied denied errors.
PS: Is there a way to pipe html to stdout?
@drwetter I'm sorry for the delay, I'm double-checking that the integration will work for your workflow (the release branches). It definitely builds on pushes to the default branch, but I don't want to get you in an annoying situation.
Sadly the snap from @kyrofa also does not solve this, as testssl --html domain just throws alot of Permission denied denied errors.
Oh I'm sorry, I haven't used that feature. The snap is confined to only be able to access the network, which means it can only write to specific places on disk. Try this for example:
$ cd ~/snap/testssl/current
$ testssl --html <domain>
It can write there, so that should work fine. It would probably make sense to add the home and removable-media plugs so it could write in $HOME and /media/*, particularly considering that other CLI args would use them as well.
@kyrofa sure, that would be awesome! I think it would be the personal-files interface or? Not sure how those work exactly though.
Tried docker, which did not work (html will be generated inside the container and then discarded).
@adrianrudnik Did you mount the host directory where you wanted to write to? See Dockerfile.md
@drwetter Ah there is another markdown. Followed the steps in https://github.com/drwetter/testssl.sh#docker and skipped the volume mounting and my next thought was to redirect stdout into a file which did not work, so I switched to snap. Maybe integrate the Dockerfile.md into the Readme.md or just link to it if there is additional information available?
Just tried a docker run --rm -t -v pwd:/data drwetter/testssl.sh --htmlfile /data/ example.com and that worked.
Maybe integrate the Dockerfile.md into the Readme.md or just link to it if there is additional information available
Good point. Will do next occasion.
I think it would be the personal-files interface or?
home allows it to write to anywhere in $HOME (with a few exceptions), and removable-media allows it to write to anywhere in /media/* and /mnt/*`. That has been released, give it a try. For example, make sure you're in your home directory somewhere and simply run the command you tried previously:
$ testssl --html <domain>