Contact

Email or Discord

Those are the two I actually watch. No Slack, no Telegram, no SMS — a message there will not reach me. There is a form further down if you would rather not open a mail client.

Email · preferred egelhaus@ennogelhaus.de Best for anything that needs a record. Security reports, scoping, work enquiries.
Discord @egelhaus Good once something's already in motion.
GitHub @egelhaus Code, and the public side of the work.

Details

Reporting a vulnerability

Email, coordinated disclosure. You'll get an acknowledgement, a scored assessment, and a timeline we agree on. There's a PGP key published for this domain over WKD if the report needs encrypting.

What a useful report contains: what you did, what happened, and what you expected instead. A version or a commit. Enough for me to reproduce it. If you have a CVSS vector in mind, send the vector rather than the number, because the vector is the part worth arguing about.

What happens next is scoping, scoring against a stated rubric, a weakness chain, a record, and a publication date we agree on. Which programme handles it depends on whose software it is in. Postiz has its own CVE Numbering Authority. My own software is covered by the Gelhaus Solutions security policy, which states the scope, the response times and the safe harbour terms.

Which one to use

Email if it needs a record. Security reports, scoping, work enquiries, anything either of us might want to point at again in six months.

Discord once something is already in motion. It is good for the back and forth, and bad as the only place a decision exists.

Language

The site is in English. German on request, for advisories, support replies and anything else.

Response time

Security reports get acknowledged first and fastest. Everything else gets a reply, but a support question about Postiz will always be answered better through the Postiz support desk than through my inbox.

What I won't answer

Recruitment for roles that clearly aren't a fit. Anything that needs internal infrastructure detail, unpublished findings, or someone else's personal data before we've even spoken.

Or write here

Send a message

What you type here is sent on by email and kept until the enquiry is dealt with. How this site handles it.

Reporting a vulnerability? Use the disclosure policy instead.

Before you write

Quick answers

Is GHub open source?

No. Open core. The base version of every app is free, Pro and Enterprise aren't, and all of it sits under a proprietary licence I hold every right to. It isn't AGPL.

Postiz, where I work, is open source. My own line isn't, and I try to keep that clear.

Why is everything UI-first?

Because a feature that only exists behind a CLI flag or an undocumented endpoint is a feature only maintainers really have.

It costs more up front. I've never regretted it.

How do I report a security vulnerability?

Email, coordinated disclosure. You'll get an acknowledgement, a scoped and scored assessment, and a timeline we agree on. There's a PGP key published over WKD if you need to encrypt it.

What is the fastest way to reach you?

Email if it needs a record. Discord if we are already mid-conversation. Those are the only two.

Do you work in German as well as English?

Yes, both, daily. Advisories, release notes and support replies go out in whichever one suits the reader.

What is Gelhaus Solutions?

The umbrella for my homelab and my personal and community projects. Separate from the Postiz role.

Why fork a project instead of contributing upstream?

Because some changes only make sense for how I work, and asking a maintainer to carry them is not fair on either of us.

Vulnogram is the clearest case. The attachment handling and CVSS vector pasting I added fit the way I run advisory work, and would be noise for a CNA that works differently. Forking was cheaper than arguing for every change, and more honest about who the changes are for.

Where the upstream wants something, it goes upstream. Postiz and the OSV work are contributions, not forks.

What does "closed source" mean on this site?

Not published. It does not mean undocumented.

Some of it is client work, where somebody paid for it and the code is theirs rather than mine to hand out. The rest is my own work I decided not to open.

Either way the entry describes the problem and what was built to solve it, because that part is mine to talk about.