On 02/04/2017 12:31 PM, Amos Jeffries wrote:
> On 3/02/2017 4:05 a.m., Alex Rousskov wrote:
>> On 02/01/2017 11:51 PM, Amos Jeffries wrote:
>>
>>> Can we agree on this being a fundamental design in Squid:
>>>
>>> * all connections have an associated socket ID.
>>
>> That assumption would be too
On 3/02/2017 4:05 a.m., Alex Rousskov wrote:
> On 02/01/2017 11:51 PM, Amos Jeffries wrote:
>
>> Can we agree on this being a fundamental design in Squid:
>>
>> * all connections have an associated socket ID.
>
> That assumption would be too limiting (and, AFAICT, unnecessary). For
> example,
On 02/01/2017 11:51 PM, Amos Jeffries wrote:
> Can we agree on this being a fundamental design in Squid:
>
> * all connections have an associated socket ID.
That assumption would be too limiting (and, AFAICT, unnecessary). For
example, SSL connections inside SSL connections (HTTPS proxy) do
On 02/02/2017 03:16 πμ, Alex Rousskov wrote:
On 02/01/2017 01:42 PM, Christos Tsantilas wrote:
must take in account that some openSSL calls
returns locket objects, and some other unlocked objects.
Does the patch start using shared pointers for any objects in the
second, "returned unlocked"
On 2/02/2017 2:28 p.m., Alex Rousskov wrote:
> On 01/19/2017 12:11 PM, Alex Rousskov wrote:
>> On 01/19/2017 12:16 AM, Amos Jeffries wrote:
>>> Well, there is no such thing as a "SSL connection" - it is security
>>> added onto some *other* Transport Protocol's layer.
>
>> There is. The "security
On 01/19/2017 12:11 PM, Alex Rousskov wrote:
> On 01/19/2017 12:16 AM, Amos Jeffries wrote:
>> Well, there is no such thing as a "SSL connection" - it is security
>> added onto some *other* Transport Protocol's layer.
> There is. The "security added onto some other Transport Protocol's
> layer"
On 02/01/2017 01:42 PM, Christos Tsantilas wrote:
> must take in account that some openSSL calls
> returns locket objects, and some other unlocked objects.
Does the patch start using shared pointers for any objects in the
second, "returned unlocked" category? AFAICT, only the SSL connection
On 19/01/2017 09:11 μμ, Alex Rousskov wrote:
Does the patched code continue to work well with OpenSSL?
You have not answered this question. Please do not commit these changes
until the OpenSSL build is tested.
Amos, asks me to make some tests if I have time. I make some simple
tests with
On 20/01/2017 8:11 a.m., Alex Rousskov wrote:
>
>>> Does the patched code continue to work well with OpenSSL?
>
> You have not answered this question. Please do not commit these changes
> until the OpenSSL build is tested.
>
Hi Christos,
Would you be able to do some tests for the mk2 patch
On 01/19/2017 12:16 AM, Amos Jeffries wrote:
> On 15/01/2017 8:09 p.m., Alex Rousskov wrote:
>> I am trying to understand how a standard std::shared_ptr can co-exist
>> with OpenSSL locking.
> whenever the shared_ptr has a non-nil value the library lock count is >= 1.
Understood, thank you. This
Ar, forgot the patch again. Please find it attached.
Amos
=== modified file 'src/Makefile.am'
--- src/Makefile.am 2017-01-08 05:12:44 +
+++ src/Makefile.am 2017-01-12 13:05:40 +
@@ -3022,44 +3022,44 @@
$(TESTSOURCES) \
SquidMath.cc \
SquidMath.h \
On 15/01/2017 8:09 p.m., Alex Rousskov wrote:
> On 01/14/2017 10:16 AM, Amos Jeffries wrote:
>
>> The Security::SessionPointer is converted to std::shared_ptr. This is
>> required because GnuTLS does not expose the locking like OpenSSL. Since
>> we store the SessionPointer to fd_table[].ssl we
On 01/14/2017 10:16 AM, Amos Jeffries wrote:
> The Security::SessionPointer is converted to std::shared_ptr. This is
> required because GnuTLS does not expose the locking like OpenSSL. Since
> we store the SessionPointer to fd_table[].ssl we can always access it
> from there one way or another
This completes the next milestone in the long journey toward GnuTLS
support: operational server connections for https:// URLs and cache_peer.
I have had to make significant changes to how the options=FOO config
settings are handled internally since GnuTLS does not expose the
priority_t
14 matches
Mail list logo
