Re: haproxy issue tracker discussion
Ansible, for example (https://github.com/ansible/ansible/issues), uses some advanced automation and templates to manage their enormous issues stream. Issue are checked against conforming rules/tests/codestyle checks or, for example, automatically closed due inactivity I believe most if not all soluitons they use are opensource. On Sun, Jan 6, 2019 at 7:32 PM Lukas Tribus wrote: > Hello everyone, > > > as per Tim's suggestion I'm restarting the discussion about the issue > tracker, started in "haproxy 1.9 status update" (2018-05-25), > Message-ID 20180525161044.ga6...@1wt.eu: > https://www.mail-archive.com/haproxy@formilux.org/msg30139.html > > > > It would be nice to show what's pending or being worked on, and > > to sometimes add extra info regarding a given task. > > Yes, we are in need of an issue tracker, not only to handle open bugs, > but even more so to handle feature/change requests that often need > more time. Those do get lost on the mailing list, even when everyone > already agreed it's needed. > > > > The problem we've faced in the past with GitHub's issue tracker > > is that it's impossible to restrict the creation of new issues to > > participants. Given that haproxy is a complex component, the boundary > > between human error, misunderstanding and bug is extremely thin. > > It is, but I don't like restricting the creation of new issues to > participants. > > Issue templates need to be clear that the issue tracker is not a > support forum. Triaging new issues will be needed anyway, and that > also includes closing misdirected support request. > > > To be clear: I think developers should not receive an email > notifications for new or untriaged issues - only when specifically > assigned to the issue or if they commented previously on it. Instead, > maybe an automated weekly report or something like that (similar to > what we have now for the stable-queue) could go out to the mailing > list with a summary of the open issues, grouped by it's labels. > > > > It resulted in the issue tracker being filled with wrong bugs, 100% of > > which were in fact requests for help. It makes the utility totally > > useless for development and bug fixing as it requires more time to > > maintain in a clean state than it takes to put issues in a mailbox. > > What you are describing basically is a unmaintained issue tracker, > which is of course useless. > > But keeping people from filing new issues is the wrong approach to > this, imho. Proper templating, triaging and correct labeling of the > issues is the difference between a useless and a useful issue tracker > from my point of view. > > > So I guess we ultimately have to decide between: > > - an issue tracker open to everyone, however requiring some > volunteers to triage incoming bugs (and close invalid ones) > - an issue tracker that is open to "previous participants", with the > expectation to require less manpower for triage > > > I'm in favor of the former, because I believe triage will be required > for both and I don't think the amount of bogus issues will be > unmanageable. I'd also volunteer to triage incoming issues - not that > it's much different from what's currently done discourse anyway - as > Tim already said. > > Regarding what tool to use, in the "open to everyone" case I'd opt for > github simply because it has the lowest barrier of entry for everyone, > as well as me being mildly familiar with it personally. Pre-existing > github labels would have to be replaced by useful ones and a issue > template would have to be created. > > > > A limitation that isn't addressed by any of them is that an issue has > > a single status and not one per maintenance branch. Some will say that > > labels replace this but I'd say that this isn't true, it just vaguely > > emulates this. Anyway if we don't have better we can go with this. I > > often dream of the day someone pissed of by using prehistoric issue > > trackers writes a modern one, just like when Linus created Git... > > There are some niche tools allowing a "distributed issue tracking > system" within git, but they seem very fragmented, none of it gets a > lot of traction and it would certainly over complicate things for a > lot of people, including myself. See git-bug [1] and it's HN > discussion [2], containing a log of other references [3-7]. > > Well I guess we would certainly not have many bogus issues reported on > those systems ;) > > > > Regards, > Lukas > > > [1] https://github.com/MichaelMure/git-bug > [2] https://news.ycombinator.com/item?id=17782121 > [3] http://bugseverywhere.org/ > [4] http://mrzv.org/software/artemis/ > [5] https://github.com/sit-fyi/issue-tracking > [6} https://github.com/dspinellis/git-issue > [7] http://travisbrown.ca/projects/nitpick/docs/nitpick.html > >
sample/fetch support for TLS extensions
I would like to propose a little patch, based on current ssl_capture
(ssl_sock.c) scheme.
Purpose is to be able to sample/fetch TLS extensions, it could be useful
for debugging or fingerprinting purposes (for example, cURL and Firefox
provide different sets of extensions in ClientHello message).
it provides two hooks, which should be enough for further Lua
processing/request forwarding/analysis: smp_fetch_ssl_fc_exts_bin,
smp_fetch_ssl_fc_exts_hex
From 32a5d13b13b530199eb2fc568c035aa68481cefb Mon Sep 17 00:00:00 2001
From: Alexey Elymanov
Date: Tue, 16 Oct 2018 15:11:44 +0300
Subject: [PATCH] MEDIUM: Sample/Fetch hooks for TLS ClientHello Extensions
Provides two new hooks, which should be enough for further Lua
processing/request forwarding/analysis: smp_fetch_ssl_fc_exts_bin,
smp_fetch_ssl_fc_exts_hex.
---
src/ssl_sock.c | 54 +-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 41833768..b48057bd 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -271,6 +271,8 @@ struct ssl_capture {
unsigned long long int xxh64;
unsigned char ciphersuite_len;
char ciphersuite[0];
+ unsigned char extensions_len;
+char extensions[0];
};
struct pool_head *pool_head_ssl_capture = NULL;
static int ssl_capture_ptr_index = -1;
@@ -1586,6 +1588,18 @@ void ssl_sock_parse_clienthello(int write_p, int version, int content_type,
global_ssl.capture_cipherlist : rec_len;
memcpy(capture->ciphersuite, msg, capture->ciphersuite_len);
+ /* Compression methods */
+msg+=rec_len;
+ /* skip, jumping to extensions */
+msg+=3;
+/* Extensions methods */
+rec_len = msg[0];
+msg += 1;
+capture->extensions_len = (global_ssl.capture_cipherlist < rec_len) ?
+ global_ssl.capture_cipherlist : rec_len;
+
+memcpy(capture->extensions, msg, capture->extensions_len);
+
SSL_set_ex_data(ssl, ssl_capture_ptr_index, capture);
}
@@ -7086,6 +7100,42 @@ smp_fetch_ssl_fc_cl_str(const struct arg *args, struct sample *smp, const char *
#endif
}
+static int
+smp_fetch_ssl_fc_exts_bin(const struct arg *args, struct sample *smp, const char *kw, void *private)
+{
+ struct connection *conn;
+ struct ssl_capture *capture;
+
+ conn = objt_conn(smp->sess->origin);
+ if (!conn || !conn->xprt_ctx || conn->xprt != &ssl_sock)
+ return 0;
+
+ capture = SSL_get_ex_data(conn->xprt_ctx, ssl_capture_ptr_index);
+ if (!capture)
+ return 0;
+
+ smp->flags = SMP_F_CONST;
+ smp->data.type = SMP_T_BIN;
+ smp->data.u.str.area = capture->extensions;
+ smp->data.u.str.data = capture->extensions_len;
+ return 1;
+}
+
+static int
+smp_fetch_ssl_fc_exts_hex(const struct arg *args, struct sample *smp, const char *kw, void *private)
+{
+ struct buffer *data;
+
+ if (!smp_fetch_ssl_fc_exts_bin(args, smp, kw, private))
+ return 0;
+
+ data = get_trash_chunk();
+ dump_binary(data, smp->data.u.str.area, smp->data.u.str.data);
+ smp->data.type = SMP_T_BIN;
+ smp->data.u.str = *data;
+ return 1;
+}
+
#if OPENSSL_VERSION_NUMBER > 0x0090800fL
static int
smp_fetch_ssl_fc_unique_id(const struct arg *args, struct sample *smp, const char *kw, void *private)
@@ -8861,7 +8911,9 @@ static struct sample_fetch_kw_list sample_fetch_keywords = {ILH, {
{ "ssl_fc_cipherlist_hex", smp_fetch_ssl_fc_cl_hex, 0, NULL,SMP_T_BIN, SMP_USE_L5CLI },
{ "ssl_fc_cipherlist_str", smp_fetch_ssl_fc_cl_str, 0, NULL,SMP_T_STR, SMP_USE_L5CLI },
{ "ssl_fc_cipherlist_xxh", smp_fetch_ssl_fc_cl_xxh64,0, NULL,SMP_T_SINT, SMP_USE_L5CLI },
- { NULL, NULL, 0, 0, 0 },
+ { "ssl_fc_exts_bin",smp_fetch_ssl_fc_exts_bin,0, NULL,SMP_T_SINT, SMP_USE_L5CLI },
+{ "ssl_fc_exts_hex",smp_fetch_ssl_fc_exts_hex,0, NULL,SMP_T_SINT, SMP_USE_L5CLI },
+{ NULL, NULL, 0, 0, 0 },
}};
/* Note: must not be declared as its list will be overwritten.
--
2.17.1
