voltone
The EEF’s Security WG has released the first public draft of the Secure Coding and Deployment Hardening Guidelines for BEAM languages.
“Secure coding practices can help reduce vulnerabilities in software projects by steering programmers away from dangerous functions or patterns, and towards more robust alternatives. Deployment hardening is the process of reducing the attack surface of a production environment, e.g. by removing unused components and revising unsafe configurations.”
We welcome feedback and suggestions through the group’s GitHub repo.
Trending in Guides/Tuts
I’ve spent some time understanding how to do hot code reloading with releases built using mix release, and here I’d like to detail the st...
New
# ~/src/livebook/.iex.exs
System.cmd("xdg-open", [ LivebookWeb.Endpoint.access_url() ] )
Because Livebook requires a unique passcode on ...
New
Other Trending Topics
Edit: 2026 May 15 - This post is archived.
Mob is alive!!
Main docs: mob v0.7.11 — Documentation
A bit of explanation for the slightly c...
New
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex











Most Liked- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
voltone
Unfortunately this has been the documented behaviour of
:ssl(and, by extension,:httpc) all along, so the OTP team does not consider this a vulnerability. It is important that everyone is aware of it, and I would highly recommend adding test cases to verify that connections fail when they should (e.g. using https://badssl.com) to any application that includes some sort of TLS client.The fact that a CA trust store is not included is no real excuse for not setting
{:verify, :verify_peer}. Ideally that would be the default, which would cause TLS clients to fail unless the caller passed in the:cacertfile/:cacertsoption or explicitly disabled verification with{:verify, :verify_none}.Exadra37
Congrats on what seems to be an excellent work, just by the quick lookup I made

LostKobrakai
I found this to be a good primer on secure ssl/httpc usage:
Maybe this would be a good resource to link to?
Last Post!
michalmuskala
Looks good, thanks!