Jeremy Daer
c860b51109
* Take the SSRF address policy from surfguard instead of keeping our own copy Four other apps carried this same classification and the five had drifted into four different ideas of what "internal" means. It now comes from the surfguard gem, which is their union. resolve and Violation keep their shapes, so the opengraph callers are unchanged. Two verdicts change. SIIT (::ffff:0:0:0/96) is now recognised. It is the third way an IPv4 address rides inside an IPv6 one and the only one Ruby has no predicate for -- ipv4_mapped?, ipv4_compat?, private?, loopback? and link_local? are all false for ::ffff:0:a9fe:a9fe, so it fell through to the IPv6 branch unrecognised and reached the metadata endpoint. Note the extra group: ::ffff:0:0:0/96 is not the IPv4-mapped ::ffff:0:0/96 the guard already refused, and the two do not overlap. The RFC 8215 local-use NAT64 block is now refused whole rather than decoded. Reading its low 32 bits as an embedded IPv4 is only correct for a /96 Pref64; the block can host any length from /32 to /96 and the position is not recoverable from the address alone (RFC 6052 2.2), so the decode reads the wrong octets. It is never globally routed, so refusing it costs nothing. The well-known /96 is still decoded and re-checked, so DNS64 for public sites on IPv6-only hosts keeps working. Resolution moves from Resolv.getaddress to Resolv.getaddresses, so the guard sees every address a host answers with rather than only the first. * Distinguish a DNS lookup failure from a private-IP block in the guard Advance the surfguard pin so resolve_public_ips raises Unresolvable when a host resolves to nothing and returns an empty list only when it resolves to a blocked address. The shim lets Unresolvable propagate as a lookup failure -- matching the old Resolv.getaddress behavior -- and reserves Violation for a resolved-but-blocked address, so a transient DNS miss is no longer reported as an SSRF attempt.
Campfire
Campfire is a web-based chat application. It supports many of the features you'd expect, including:
- Multiple rooms, with access controls
- Direct messages
- File attachments with previews
- Search
- Notifications (via Web Push)
- @mentions
- API, with support for bot integrations
Running your own Campfire instance
Campfire's Docker image contains everything needed for a fully-functional,
single-machine deployment. This includes the web app, background jobs, caching,
file serving, and SSL. You can use our pre-built image at
ghcr.io/basecamp/once-campfire:latest, or build your own from this repo.
Deploying with ONCE
The easiest way to self-host Campfire is with ONCE. It will guide you through the initial set up and then keep your instance up to date automatically.
If you don't already have once installed, run this on the machine you want to run Campfire on:
curl https://get.once.com | sh
once will launch as soon as the install is finished.
Choose Campfire from the list of applications, follow the instructions, and ONCE will take care of the rest.
If you prefer the command line to the dashboard, you can deploy directly:
once deploy ghcr.io/basecamp/once-campfire --host chat.example.com
Deploying with Docker
If you'd rather run the Docker image yourself, you can read more about that in the self-hosting guide.
Tip
When you start Campfire for the first time, you'll be guided through a wizard to create an admin account. The email address that you enter for the admin account will be visible on the sign-in page, it's there so that people have someone to contact if they need help with their account. If that bothers you, put in any email address you want and create yourself a new admin account.
Development
You are welcome - and encouraged - to modify Campfire to your liking. Please see our development guide for how to get Campfire set up for local development.
Security
See SECURITY.md for how to report a vulnerability and a description of our trust model.