lyskomd-qa

lyskomd-qa@lists.lysator.liu.se

1047 discussions

[Bug 1715] New: yyerror() should not have format string attribute, since that is incompatible with yacc-generated code
by bugzilla-daemon＠lysator.liu.se 28 Jul '16

28 Jul '16

https://bugzilla.lysator.liu.se/show_bug.cgi?id=1715 Bug ID: 1715 Summary: yyerror() should not have format string attribute, since that is incompatible with yacc-generated code Classification: LysKOM Product: lyskomd Version: 2.1.2 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 Component: server Assignee: ceder(a)lysator.liu.se Reporter: holmgren(a)lysator.liu.se QA Contact: lyskomd-qa(a)lists.lysator.liu.se yacc/bison expects yyerror() to take only a char const *. Adding __attribute__ ((format (printf, 1, 2))) causes a compilation error when compiling with -Werror=format-security, which happens to be what at least Debian tries to do nowadays (for good reasons). Either remove the attribute or rename the function and make yyerror() a wrapper or macro that calls the original function with "%s" as the first argument. See https://bugs.debian.org/643446#25 -- You are receiving this mail because: You are the QA Contact for the bug.

1 0

[Bug 1714] New: Should we disable Nagle's algorithm?
by bugzilla-daemon＠lysator.liu.se 14 Apr '16

14 Apr '16

https://bugzilla.lysator.liu.se/show_bug.cgi?id=1714 Bug ID: 1714 Summary: Should we disable Nagle's algorithm? Classification: LysKOM Product: lyskomd Version: master (unreleased) Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: server Assignee: ceder(a)lysator.liu.se Reporter: ceder(a)lysator.liu.se QA Contact: lyskomd-qa(a)lists.lysator.liu.se Maybe we should disable Nagle's algorithm in lyskomd? I think we do a pretty decent job in buffering the data and sending it in large chunks, so we should maybe use this: int on = 1; setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on)); -- You are receiving this mail because: You are the QA Contact for the bug.

1 0

[Bug 1710] New: Standardize mx-allow-envelope-sender-regexp
by bugzilla-daemon＠lysator.liu.se 03 Jul '15

03 Jul '15

https://bugzilla.lysator.liu.se/show_bug.cgi?id=1710 Bug ID: 1710 Summary: Standardize mx-allow-envelope-sender-regexp Classification: LysKOM Product: lyskomd Version: master (unreleased) Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: documentation Assignee: ceder(a)lysator.liu.se Reporter: ceder(a)lysator.liu.se QA Contact: lyskomd-qa(a)lists.lysator.liu.se The mx-allow-envelope-sender-regexp aux-item should be standardized. Proposed wording: @item mx-allow-envelope-sender-regexp [10105] (conference, letterbox) Data is a Python-style regular expression. If any aux-item of this type is set on a conference or letterbox, the envelope sender of an email must match at least one of them, or the mail importer will refuse to import the mail. End proposed wording. The main reason to standardize this aux-item is so that it may have owner-delete set. As things stand now, most anybody can set an mx-allow-envelope-sender-regexp aux-item on a conference, and the supervisor(s) of the conference cannot remove it. That is not a good thing. But, for this to happen, the komimportmail authors must agree to change the type of aux-item 10105 to predefined. -- You are receiving this mail because: You are the QA Contact for the bug.

1 0

[Bug 1707] New: test bug (please ignore)
by bugzilla-daemon＠lysator.liu.se 04 Nov '14

04 Nov '14

https://bugzilla.lysator.liu.se/show_bug.cgi?id=1707 Bug ID: 1707 Summary: test bug (please ignore) Classification: LysKOM Product: lyskomd Version: master (unreleased) Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: testsuite Assignee: ceder(a)lysator.liu.se Reporter: ceder(a)lysator.liu.se QA Contact: lyskomd-qa(a)lists.lysator.liu.se Testing the Bugzilla system... -- You are receiving this mail because: You are the QA Contact for the bug.

1 1

[Bug 1704] New: Password reset mechanism
by bugzilla-daemon＠lysator.liu.se 11 Sep '14

11 Sep '14

https://bugzilla.lysator.liu.se/show_bug.cgi?id=1704 Bug ID: 1704 Summary: Password reset mechanism Classification: LysKOM Product: lyskomd Version: master (unreleased) Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: server Assignee: ceder(a)lysator.liu.se Reporter: ceder(a)lysator.liu.se QA Contact: lyskomd-qa(a)lists.lysator.liu.se >From time to time, users forget their password. That means that I have to manually set a new password. More often than not the password is sent in clear text via mail. A better mechanism is needed. -- You are receiving this mail because: You are the QA Contact for the bug.

1 1

[Bug 133] Cryptography needed
by bugzilla-daemon＠lysator.liu.se 08 Aug '14

08 Aug '14

https://bugzilla.lysator.liu.se/show_bug.cgi?id=133 Albin Sunnanbo <albin(a)sunnanbo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |albin(a)sunnanbo.com --- Comment #21 from Albin Sunnanbo <albin(a)sunnanbo.com> --- There is a race condition during TLS initialization if the server decides to send async during between the client has requested TLS initialization and the initialization actually starts. See discussion in LysLys ====================================================================== Author: Albin! (Hej, vad har du kompilerat idag?) Text No: 17466434 Creation time: 2009-04-14 19:25:35 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- * Dokumentationen bör påpeka att det är bra att sätta accept-async till tomma listan innan man ger sig på start-tls, annars är chansen mycket god att man får en async (t.ex. att man själv loggat in) emellan när man tror att man skall få svar på sin TLS handshake... ====================================================================== Author: Anders E Larsson (andersrymdblogg.wordpress.com) Text No: 17466458 Creation time: 2009-04-14 19:32:19 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Vore det helt befängt att försöka få servern att hålla inne med asynkrona meddelanden tills TLS hoppat igång? Det känns som en gotcha man skulle kunna slippa. ====================================================================== Author: Albin! (Hej, vad har du kompilerat idag?) Text No: 17466493 Creation time: 2009-04-14 19:50:22 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Jag tänkte också det först... men det är bara det att servern inte vet om klienten tänker köra en start-tls förrän klienten verkligen gjort det, och då är det redan försent, för då kan det redan ligga ett antal asyncs ute på tråden... Man skulle ev. kunna låta tls-supported pausa alla asyncs, men det känns väldigt subtilt. En annan möjlighet är att i den nya server-versionen alltid börja med alla asyncs avlsagna, men då riskerar man att ha sönder en mängd gamla klienter. ====================================================================== Author: ceder (-) Per Cederqvist Text No: 17466865 Creation time: 2009-04-14 22:19:58 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Nu vet jag inte hur patchen gör, för jag har inte hunnit studera den, men jag tycker start-tls borde vara definierad så här: - Klienten skickar start-tls. - Servern svar skickas i klartext. - Om server svarar att start-tls gick fel (t ex för att stöd för TLS inte finns, eller nekas av administrativa skäl), så händer inget mer. Klienten får inte börja göra en TLS-handskakning. Klienten kan koppla ner förbindelsen om den är paranoid (och bör nog göra det per default, om den någonsin lyckats köra TLS mot just den servern). - Om servern svarar att start-tls lyckades, så måste klienten påbörja TLS-handskakningen. Servern garanterar att inget data skickas innan TLS-handskakningen avslutats. - Själva TLS-handskakningen kan misslyckas. Då skickas (så vitt jag förstår) alltid en alert som beskriver vad som hänt. När en sådan alert har skickats är förbindelsen åter i klartext (eller så ska protokoll A speca att förbindelsen ska kopplas ner). - Om TLS-handskakningen lyckas, så slutar den med att medelandet "Finished" skickas i vardera riktningen. Direkt när "Finished" skickats kan man börja sända krypterade meddelanden. Asynkrona meddelanden borde inte vara något problem. Servern borde automatiskt se till att inte skicka något efter svaret på start-tls, utan invänta klientens TLS-handskakning. (Och kommer det ingen TLS-handskakning inom någon timme eller så ska servern koppla ner!) ====================================================================== ... ====================================================================== Author: ceder (-) Per Cederqvist Text No: 17467612 Creation time: 2009-04-15 09:21:10 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Jag skulle som sagt föredra det här: C: 0 999 # Om "999" är START-TLS S: =0 C: ClientHello S: ServerHello Men om det blir enklare kan man ju i stället tänka sig att man gör så här: C: 0 999 S: =0 C: ClientHello S: <eventuella asynkrona meddelanden> S: <ett nytt asynkront meddelande: "tls-handskakningen börjar nu"> S: ServerHello Men att ha det så här tror jag fungerar dåligt: C: 0 999 S: =0 C: ClientHello S: <eventuella asynkrona meddelanden> S: ServerHello Nu har jag i och för sig inte tittat på hur ett ServerHello ser ut, byte för byte. Eftersom serverns svar alltid börjar med "=", "%" eller ":", så kanske man kan se skillnad på de och ServerHello? Fast det känns inte så stabilt. ====================================================================== Author: Albin! (Hej, vad har du kompilerat idag?) Text No: 17469342 Creation time: 2009-04-15 20:42:41 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Jag skulle föredra den första varianten. ====================================================================== Author: Albin! (Hej, vad har du kompilerat idag?) Text No: 17469370 Creation time: 2009-04-15 20:57:41 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Variant två blir inte så bra att implementera i .NET i alla fall, när jag börjar min handshake så tar den över inkommande dataström direkt och den måste alltså vara "framme" innan jag startar mitt ClientHello. C: 0 999 S: =0 S: <eventuella asynkrona meddelanden> S: <ett nytt asynkront meddelande: "tls-handskakningen börjar nu"> C: ClientHello S: ServerHello Skulle också kunna funka. Men det känns inte helt stabilt med ett protokoll som säger "någon gång i framtiden så kommer vi börja". ====================================================================== -- You are receiving this mail because: You are the QA Contact for the bug.

1 0

[Bug 133] Cryptography needed
by bugzilla-daemon＠lysator.liu.se 08 Aug '14

08 Aug '14

1 0

[Bug 133] Cryptography needed
by bugzilla-daemon＠lysator.liu.se 08 Aug '14

08 Aug '14

1 0

[Bug 133] Cryptography needed
by bugzilla-daemon＠lysator.liu.se 08 Aug '14

08 Aug '14

1 0

[Bug 1702] New: IPv6: DNS requests block the server
by bugzilla-daemon＠lysator.liu.se 05 Aug '14

05 Aug '14

https://bugzilla.lysator.liu.se/show_bug.cgi?id=1702 Bug ID: 1702 Summary: IPv6: DNS requests block the server Classification: LysKOM Product: lyskomd Version: master (unreleased) Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: server Assignee: ceder(a)lysator.liu.se Reporter: ceder(a)lysator.liu.se QA Contact: lyskomd-qa(a)lists.lysator.liu.se When a client connects, the server tries to resolve the IP address of the client. In the beginning, this was done in a blocking way. Bug 627 added non-blocking lookup of IPv4 addresses, but IPv6 adresses are still looked up in a blocking way. We need to add IPv6 support to adns and possibly the liboop adapter. (If we are lucky, newer versions of adns have the necessary support. Check that.) There is code in src/libraries/libisc-new/src/isc_socket.c that checks for this condition: /* adns does not yet support IPv6 addresses, so if this is an IPv6 socket we have to use the old blocking method of host name lookup. */ -- You are receiving this mail because: You are the QA Contact for the bug.

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

lyskomd-qa