Repository navigation
Conversation
|
Just two comments at first glance:
|
graysky2
changed the title
45cc5d3 to
5cd6b8b
Compare
|
Yeah, I wrestled with whether or not I should make it consistently named throughout. It is now. As to the privacy piece, I don't think I agree. If you're installing a package that writes log files, you're opting in to that behavior. Otherwise what's the point? |
e2e0e62 to
114fad0
Compare
|
Thanks for unifying the naming. On the default I see it a bit differently: installing a package isn't quite the same as deciding to record peers' IPs. For something that builds a history of other people's public IPs, I'd prefer an explicit opt-in ( |
|
Could you please add an argument for why somebody would want to have this? In Europe, this package would e.g. be in conflict with GDPR-mandated data minimization. |
|
@dibdot @ArwedSchmidt are you both disabling your ssh server logs ?? Because it contains the same kind of information (time user IP) GDPR doesn't prevent you from having audit logs, and CRA even mandates having them. |
|
It would derail the topic here but yes, there is a limit on how long you can store personal information. It doesn't mean you cannot have audit logs (especially in companies) but this package currently does not implement any controls regarding how long data about IPs belonging to a permanently identifying key is stored nor does it even require explicit approval by the system owner before it captures such data. It could simply be included in some distributed firmware files without the system owner taking note of it. Systems running OpenWrt can run for a long time, sometimes years. Not to mention that system owners likely won't get a consent from their users before storing personal data.. If it would implement something like keep it max for 7-28 days by default, the package might be seen differently than how it looks right now. If somebody wants to do something like this package does, they would be free to do so on their own systems - why a package 'for the general public'? |
|
Retention limits apply to all the logs (ssh/luci/dnsmasq/hostapd/openvpn/... all contain PII), so it's way more sensible to send everything to syslog and manage retention policy in a single place than try to reimplement log management in every software. You said it yourself, companies are required by law to have audit logs (and security conscious people also want logs), so why not have a package ready to install ? Wireguard is the exception here, the norm is audit logs by default. |
|
Agree that retention belongs in the syslog/logd layer, not in each package — and by default this only goes to the logd ring buffer anyway, same as dropbear. The one difference to ssh logs is granularity: every endpoint change on a roaming peer is closer to a movement trail than a login record, which is why I'd still lean towards an explicit opt-in. But as said before, that's the maintainer's call, not a blocker from my side. I’m definitely not going to use the package. |
I'm no lawyer but I believe if this is getting done on a home router, you're logging your own peers and that's fine under the household exemption. |
114fad0 to
30e9a09
Compare
openwrt-ai
left a comment
openwrt-ai
left a comment
There was a problem hiding this comment.
Commit checks
- 30e9a09 "wireguard-endpoint-log: add new package" — the example log (
ip_only=0, endpoints with ports, no geo fields) describes older behaviour, not v1.4 (ip_only=1,asn=1,geoip=1, City/Country/ISP/ASN via ipinfo.io). Update the example and mention the ipinfo.io lookups; also fix the typo "outpus" → "outputs".
Generated by Claude Code
30e9a09 to
3cda729
Compare
openwrt-ai
left a comment
openwrt-ai
left a comment
There was a problem hiding this comment.
Commit checks
- 3cda729 "wireguard-endpoint-log: add new package": the example log in the body (
ip_only=0, endpoints with ports, no City/Country/ISP/ASN fields) does not match v1.4's defaults, and the body never mentions the ipinfo.io lookups that the package description now documents. Update the example and add one line about the lookups. Also, "outpus" should be "outputs".
Generated by Claude Code
3cda729 to
d3686db
Compare
Simple daemon that logs each new source endpoint seen per WireGuard peer public key, to syslog or optionally to a file on persistent storage. Rationale: WireGuard keeps no history of who connected and from where. It's silent by design: wg show output only each peer's current endpoint, and the moment it changes, the old one is gone. So if you ever want to know where a key has been used from, stock OpenWrt has nothing. From the README.md: Written to syslog (`logread -e wireguard-endpoint-log`). `log_file` format: ``` 20261031-05:06:02 started interval=2s ip_only=0 20261031-05:06:25 iface=wg0 peer=myphone endpoint=70.172.116.173:57891 pubkey=xr4l...3TQ= 20261031-05:08:15 iface=wg0 peer=wifephone endpoint=207.119.148.124:61500 pubkey=gDTT...C2U= 20261031-05:09:33 iface=wg1 peer=basecamp endpoint=103.102.36.53:51110 pubkey=8Nf/...m0= ``` Signed-off-by: John Audia <therealgraysky@proton.me>
d3686db to
6558ead
Compare
📦 Package Details
Maintainer: me
Description:
Small daemon that logs each change in the source address every WireGuard peer key pair connects from on OpenWrt, making it possible to spot a key pair being used by someone other than its owner.
Rationale:
(From project README):
WireGuard does not log connections. If a peer's private key is copied off a lost phone, a backup or a shared config, whoever has it can connect as that peer and nothing on the router easily shows that record. How do you know someone didn't connect overnight using a compromised key? You don't. Until now.
A typical home setup has a handful of peers: phones for family members, a laptop or tablet, maybe a remote site. Each one tends to connect from a small, predictable set of networks: the home ISP, a mobile carrier, work/school etc. all of which are in the same region. This log is an audit trail of every place each key pair has connected from, so the administrator can look back and check that the pattern holds.
A peer that suddenly connects from an unfamiliar ISP, a hosting provider or VPN, or a city/country its owner has never been to is a huge red flag that the key pair may be compromised. The log this generates allows for easy review of where the device's connection originated.
Example log:
Pro-tip: align output for easier reading with the
columnpackage:🔬 Run Testing Details
✅ Formalities
messages.
If your PR contains a patch:
git am