Created attachment 254889 [details] [PATCH] [NEW PORT] security/hidden-lake: F2F Anonymous network based on the QB-problem The Hidden Lake is an anonymous network built on a micro-service architecture. At the heart of HL is the core - HLS (service), which generates anonymizing traffic and combines many other services (for example, HLF and HLM). Thus, Hidden Lake is not a whole and monolithic solution, but a composition of several combined services. The HL is a friend-to-friend (F2F) network, which means building trusted communications. Due to this approach, members of the HL network can avoid spam in their direction, as well as possible attacks if vulnerabilities are found in the code.
Created attachment 254965 [details] [PATCH] [NEW PORT] security/hidden-lake: F2F Anonymous network based on the QB-problem
Created attachment 255075 [details] [PATCH] [NEW PORT] security/hidden-lake: F2F Anonymous network based on the QB-problem Version 1.7.5
Created attachment 255189 [details] [PATCH] [NEW PORT] security/hidden-lake: F2F Anonymous network based on the QB-problem Version 1.7.6
Created attachment 255674 [details] [PATCH] [NEW PORT] security/hidden-lake: F2F Anonymous network based on the QB-problem Version 1.7.7
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c543b2f674564560584e66839f6493a79b02a9d9 commit c543b2f674564560584e66839f6493a79b02a9d9 Author: Jason W. Bacon <jwb@FreeBSD.org> AuthorDate: 2024-12-06 23:16:19 +0000 Commit: Jason W. Bacon <jwb@FreeBSD.org> CommitDate: 2024-12-06 23:16:19 +0000 security/hidden-lake: F2F Anonymous network based on the QB-problem The Hidden Lake is an anonymous network built on a micro-service architecture. At the heart of HL is the core - HLS (service), which generates anonymizing traffic and combines many other services (for example, HLT and HLM). Thus, Hidden Lake is not a whole and monolithic solution, but a composition of several combined services. The HL is a friend-to-friend (F2F) network, which means building trusted communications. Due to this approach, members of the HL network can avoid spam in their direction, as well as possible attacks if vulnerabilities are found in the code. PR: 282504 Reported by: alster@vinterdalen.se Test by: jwb security/hidden-lake/Makefile (new) | 41 ++++++++++++++++++++++++++++++++++++ security/hidden-lake/distinfo (new) | 5 +++++ security/hidden-lake/pkg-descr (new) | 9 ++++++++ security/hidden-lake/pkg-plist (new) | 13 ++++++++++++ 4 files changed, 68 insertions(+)
For future new ports, please format pkg-descr to 70 columns or less, as it will be included in the commit message. fmt -w 70 pkg-descr > temp mv temp pkg-descr Otherwise, nicely done!
(In reply to Jason W. Bacon from comment #6) Thank you! I'm glad to see my new port welcomed :) I fully agree with you on 70 columns width limit and could with pleasure reformat all my existing ports to this value just now :) I'm just somewhat unsure how to deal with other people ports' pkg-descrs: whether I also should/may reformat these when updating the port versions? And if so, could you, please, point me to some rather wide agreed-on source I may provide as a justification for such my changes? I can, of course, point to the GNU/Emacs manual [0] stating 70 columns as a default I use myself, but how should I explain it to others? I myself do understand the need and practical reasons behind it (i.e. for multi-level citations in E-mail), just always feel rather uncomfortable arguing with people here. If we really like to promote 70 as a real default (I do) without much conflicts, I may just expect elders (like you) to agree on this first and publish their decision, then me just following and promoting their standards (this is what I usually do as a newcomer). I already was using 70 as my default, until was told by someone here to use 80 instead, so had to reformat. What am I to do? [0]
(In reply to Älven from comment #7) The main reason is FreeBSD commit messages have a hard 72-column limit, and convention for new ports is: category/port: COMMENT (condensed if necessary) pkg-descr So 80 won't work for new ports. There isn't a strong motive to change it for existing ports in my view. If you do, it should probably be done in a separate commit with only cosmetic changes, so that these changes don't clutter git diffs for more interesting changes. But I wouldn't do a commit just to reduce pkg-descr from 80 columns to 70. That would just be noise in the git log. If a Makefile doesn't pass portlint, or pkg-descr is being rewritten, that would be the time to reformat to 70 cols.
You forgot to add security/Makefile. Fixed: https://cgit.freebsd.org/ports/commit/?id=e3d13819404299b9ef6d272a17479c723518b48e
Ah, thanks... Bug in my commit script.
(In reply to Zsolt Udvari from comment #9) Thank you! :) It helped me with bug #283743. It's fixed now. Happy New Year! :)