Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Sviatoslav Sydorenko
    @webknjaz
    Hi @drwetter, your account/repo seems to be missing @ github
    Dirk Wetter
    @drwetter
    Thx, not missing. I can edit. Hope it'll be visible for the public soon again.See https://twitter.com/drwetter/status/876487128997404672
    Dirk Wetter
    @drwetter
    Ok, my account is again online.
    KwadroNaut
    @KwadroNaut
    Hej, I noticed that you're not using the master branch anymore. Is this intentional?
    I find it easy to stick to $somebranch of $project, to keep up-to-date, without having to fingure out tags and the like.
    There's no such thing anymore, correct?
    Dirk Wetter
    @drwetter
    Correct. If I see that correctly I can not have 'master' or 'dev' pointing to $version. So the rule of thumb is that the odd numbered version also containing 'dev' is the development version and the even number before is the stable release.
    Oliver Stöneberg
    @firewave
    hello
    Dirk Wetter
    @drwetter
    hi Oliver
    Oliver Stöneberg
    @firewave
    nevermind - I created an issue and my question have already been answered by dcooper16.
    Jeroen Wiert Pluimers
    @jpluimers
    I found I had not updated my fork for a long while, which still has the master branch. Where did that go to in https://github.com/drwetter/testssl.sh and why?
    https://github.com/jpluimers/testssl.sh/tree/master
    Franklin Yu
    @FranklinYu
    @jpluimers If you are still looking for it, https://github.com/drwetter/testssl.sh/tree/2.8 is the current tip. It's the stable branch, with latest commit drwetter/testssl.sh@0eb88ff. I think @drwetter strongly suggest 2.9 branch though.
    Dirk Wetter
    @drwetter
    @franklinyu / all. Before somebody is picking up the deprecated branch: 2.9.5-X is stable.
    Jeroen Wiert Pluimers
    @jpluimers
    @drwetter / @franklinyu thanks.
    Jeroen Wiert Pluimers
    @jpluimers
    @drwetter you can also ping me here on the 24th.
    (I'll try to remember myself, but life has not been less busy lately)
    Franklin Yu
    @FranklinYu
    Latest release 2.9.5-6 suggests switching to 3.0rcX. What is that? A branch or a tag?
    Dirk Wetter
    @drwetter
    3.0rc1 is now a tag in the 2.9dev branch
    Franklin Yu
    @FranklinYu
    2.9.5-6 is on 2.9-dev branch, not on 2.9.5 branch?
    Dirk Wetter
    @drwetter
    My bad, thx. I shouldn't do things when I am in a hurry. 2.9.5-7 corrects this
    Franklin Yu
    @FranklinYu
    Good. I'm thinking about renaming 2.9dev branch to master?
    Dirk Wetter
    @drwetter
    I should write an FAQ for this. See above (11th July 2017_
    Franklin Yu
    @FranklinYu
    You mean :point_up: July 11, 2017 11:32 AM ? I don't quite get it, to be frank... I understand that current development has been placed on 2.9dev, and even number stands for stable release (GTK team does something similar), but how is that different from calling it master?
    Dirk Wetter
    @drwetter
    because IMO master it an unfortunate naming if I also have dev. The best thing is if I could use master and dev as pointers but that's not what github offers
    Franklin Yu
    @FranklinYu
    So master in you mind is "end user should check out this branch and expect it to work"? I thought "master branch is under development and end user should download releases" is widely accepted.
    Dirk Wetter
    @drwetter
    It led to confusion
    here
    Franklin Yu
    @FranklinYu
    Currently if I do ./testssl.sh www.example.com, it resolves the IP and then make a TCP connection with the IP, as expected. However, if I ./testssl.sh --proxy proxy.example.com:8080 www.example.com, it still seems to be resolving the domain name locally. Is that the case? Why?
    Dirk Wetter
    @drwetter
    shouldn't be the case. There's a ENV variable DNS_VIA_PROXY which is set to true per default
    Franklin Yu
    @FranklinYu
    I tested with version 3.0rc3, I think the latest pre-release
    Franklin Yu
    @FranklinYu

    Is it DNS via the HTTP tunnel? What does that mean? I thought that after

    CONNECT example.host.com:22 HTTP/1.1

    I should be directly talking with example.host.com?

    Franklin Yu
    @FranklinYu
    Dirk Wetter
    @drwetter
    Certainly not "directly" from a network perspective. That's the point from a proxy. It relays everything with the CONNECT method
    Christian Moore
    @shamelesscookie

    Trying to use drwetter/testssl.sh Docker image ID 0447630f7b8a from 30 hrs ago results in error:

    Fatal error: hexdump is from busybox. Please install a regular binary

    Christian Moore
    @shamelesscookie
    I was able to build a working Docker image by adding four packages to the Dockerfile: util-linux, grep, gawk, and sed
    Dirk Wetter
    @drwetter
    hmm, let me look into it
    Dirk Wetter
    @drwetter
    I actually enforced the usage of non-busybox binaries after drwetter/testssl.sh#1225 in testssl.sh itself -- as a user had a problem with the busybox ps. But it sounds to me I could relax that a bit
    Christian Moore
    @shamelesscookie
    Up to you. It seems to work just as well if you install the packages above using apt
    Dirk Wetter
    @drwetter
    Dirk Wetter
    @drwetter
    done
    Christian Moore
    @shamelesscookie
    :thumbsup: working again! Thanks
    Thomas Ward
    @teward
    @drwetter so, digging into what you poked me about, regarding IDN, emoji domains aren't valid against IDNA2008
    so the issue with IDN support generally here is if we support IDN we can't support Emojis which are outside the IDNA2008 allowed set
    which is the git issues and host issues you were running into, punycode or not
    closest we could do is use idn2 and enforce IDNA2008 and error whenever the specified URI contains things not permitted by IDNA2008
    therefore actual international scripts, i.e. Russian, will work, but emojis won't
    to quote Namecheap:
    To be successfully registered, an IDN domain name must be valid according to IDNA2008. Emojis cannot be used as IDNs as these code points are disallowed under the IDNA2008 protocol.
    so if we exclude Emoji domains as invalid because they are against IDNA2008, then the solution I detailed in my response to the issue ticket and your inquiry would 'solve' the issue.
    but we'd be forced to exclude Emoji domains because IDNA2008