# security.txt for Security BSides Dehradun 0x03
# https://bsidesdehradun.com/.well-known/security.txt
#
# Machine-readable vulnerability disclosure contact, per RFC 9116.
#
# SCOPE: this file covers the WEBSITE ONLY.
#
# bsidesdehradun.com is a static brochure site: hand-written HTML, CSS and a
# little vanilla JavaScript, no server-side code, no database and no accounts.
# There are two forms, both handled by the host at the edge, and two analytics
# tools, Google Analytics 4 and Microsoft Clarity, which load only after a
# reader accepts them in the consent panel. Nothing here stores a reader's
# data on our own infrastructure, because we do not run any. Realistically the
# findings worth reporting are hosting and DNS misconfigurations, a mistake in
# the Content-Security-Policy, a way to make an analytics tag load before
# consent, or a hijackable link.
#
# NOT in scope, and please do not report it here:
#   * the conference CTF. It is meant to be broken; that is the event
#   * the villages, likewise
#   * ticketing on KonfHub and CFP submissions on cfp.directory, both
#     third-party platforms on their own domains with their own disclosure
#     programmes. Report to them, not to us; we cannot fix their code.
#   * Google Analytics and Microsoft Clarity themselves, vendor products on
#     vendor domains, each with its own disclosure programme. A way to make
#     either tag load before consent, or to keep it running after a reader
#     withdraws, is OUR bug and very much in scope. A bug inside their code is
#     theirs.
#
# We are a volunteer-run community conference. There is no bug bounty and no
# money. What we can offer is a prompt reply from a human, a fix, and public
# credit if you want it.

Contact: mailto:conference@bsidesdehradun.com
Contact: mailto:info@bsidesdehradun.com

# Contact lines are listed in the reporter's order of preference, most preferred
# first, which is what the ordering above means.
#
# Six mailboxes are confirmed to exist: info@, cfp@, sponsors@, support@,
# conference@ and ak@. There is still no dedicated security@ alias, and
# inventing one here would produce a file that looks correct and bounces every
# report, the single worst outcome for a security conference.
#
# conference@ is first because it reaches the founding team and the team leads,
# which is the shortest path from a report to somebody who can change the DNS,
# the headers or the host. info@ is second because it is the address in the
# footer of every page, so a reporter who never opens this file still lands
# somewhere that works. The vulnerability paragraph of code-of-conduct.html
# gives conference@ too, so a scanner and a person are told the same thing.
#
# LAUNCH ITEM: if the team creates security@bsidesdehradun.com, make it the
# first Contact line and keep both of these beneath it.

Expires: 2027-08-01T00:00:00+05:30

# MAINTENANCE TRAP, and the reason this file needs a diary entry rather than
# just a commit: Expires is mandatory, and once the date passes the file is
# formally invalid, tooling will treat the contact as unmaintained even
# though the mailbox still works.
#
# The date above is set to sit comfortably after the event on 3–4 April 2027,
# so it stays valid through the conference and the weeks of follow-up after it.
# RFC 9116 asks for less than a year out, so it cannot simply be set to 2030.
#
# Roll it forward when planning 0x04.

Preferred-Languages: en

# English only, stated honestly rather than aspirationally. Several of the
# organising team read Hindi, but this field is a promise about which language
# a report will be understood and acted on in, and that promise has not been
# agreed. Add `hi` here once the team confirms they are happy to receive and
# triage reports in Hindi. It costs nothing and it is a genuine courtesy.

Canonical: https://bsidesdehradun.com/.well-known/security.txt

# Canonical tells a reader which URL this file is authoritative at, so a copy
# found somewhere else, on a mirror, a staging domain or an archive, cannot be
# passed off as ours. If the domain changes, this line changes with it. See
# the note in robots.txt for the one grep that finds every hardcoded origin.

# Deliberately omitted
#
# Policy. There is no separate vulnerability-disclosure policy page to point
#   at, and pointing at the Code of Conduct would be wrong: the CoC governs
#   behaviour at the event, not how a security report is handled. An honest
#   omission beats a link that misleads.
#
# Encryption: no OpenPGP key has been published. A key nobody holds the
#   private half of is worse than no key: reports get encrypted to it and
#   become unreadable. Publish one, then add the line.
#
# Acknowledgments: nothing to acknowledge yet. Add a page and link it here
#   after the first report is fixed; credit is most of what we have to give.
#
# Hiring. We do not employ anyone. Volunteers are recruited through the
#   community channels in the site footer.
#
# This file is unsigned. RFC 9116 permits a detached PGP signature and it is
# genuinely nice-to-have on a security conference's own site, but see the
# Encryption note: it needs a key the team actually controls and can rotate.