[ resending with correct meeting day ]
On 7/12/21 12:57 PM, Gerald Combs wrote:
Hi everyone,
I've scheduled the next remote Developer Den for Wednesday, July 28th. This is
the remote version of the Developer Den at SharkFest, a room that is set aside
for office hours where everyone is welcome
Hi everyone,
I've scheduled the next remote Developer Den for Wednesday, July 28th. This is
the remote version of the Developer Den at SharkFest, a room that is set aside
for office hours where everyone is welcome to stop in, say hello, ask
questions, etc.
The link below has a "join from brow
> The minimum version being stuck at 1.5.0 is, I believe, almost entirely due
> to RHEL/CentOS 7 being stuck at 1.5.3
> (https://gitlab.com/wireshark/wireshark/-/wikis/Development/Support_library_version_tracking#libgcrypt)
> It's a widely used enough distribution, still scheduled for 3 more yea
> If some changes were done to fix the compilation, it means that some people
> still use a libgcrypt version older than 1.6.0.
> And as seen in our CMakeLists.txt file, the minimum version required for now
> is 1.5.0.
I understand your reluctancy to upgrade the requirements, but don’t you think
On Tue, Jul 13, 2021 at 2:26 AM Pascal Quantin wrote:
> Hi Matthias,
>
> Le lun. 12 juil. 2021 à 21:22, Dr. Matthias St. Pierre <
> matthias.st.pie...@ncp-e.com> a écrit :
>
>> Hi all,
>>
>> in wsgcrypt.h the libgcrypt version is checked to ensure that it supports
>> AEAD ciphers:
>>
>> #
Hi Matthias,
Le lun. 12 juil. 2021 à 21:22, Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> a écrit :
> Hi all,
>
> in wsgcrypt.h the libgcrypt version is checked to ensure that it supports
> AEAD ciphers:
>
> #if GCRYPT_VERSION_NUMBER >= 0x010600 /* 1.6.0 */
> /* Whether
Hi all,
in wsgcrypt.h the libgcrypt version is checked to ensure that it supports AEAD
ciphers:
#if GCRYPT_VERSION_NUMBER >= 0x010600 /* 1.6.0 */
/* Whether to provide support for authentication in addition to
decryption. */
#define HAVE_LIBGCRYPT_AEAD
#endif
On 12/07/21 19:48, Evan Huus wrote:
On Mon, Jul 12, 2021 at 14:42 João Valverde via Wireshark-dev
mailto:wireshark-dev@wireshark.org>> wrote:
On 12/07/21 19:13, Evan Huus wrote:
> On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev
> mailto:wireshark-dev@wireshark.
On Mon, Jul 12, 2021 at 14:42 João Valverde via Wireshark-dev <
wireshark-dev@wireshark.org> wrote:
>
>
> On 12/07/21 19:13, Evan Huus wrote:
> > On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev
> > wrote:
> >>
> >>
> >>
> >> On 12/07/21 16:52, Evan Huus wrote:
> >>> I've been thin
On 12/07/21 19:13, Evan Huus wrote:
On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev
wrote:
On 12/07/21 16:52, Evan Huus wrote:
I've been thinking recently about starting the process of getting rid
of the "global" wmem scope methods (wmem_packet_scope,
wmem_file_scope, etc)
On Mon, Jul 12, 2021 at 2:05 PM João Valverde via Wireshark-dev
wrote:
>
>
>
> On 12/07/21 16:52, Evan Huus wrote:
> > I've been thinking recently about starting the process of getting rid
> > of the "global" wmem scope methods (wmem_packet_scope,
> > wmem_file_scope, etc) in favour of passing the
On 12/07/21 16:52, Evan Huus wrote:
I've been thinking recently about starting the process of getting rid
of the "global" wmem scope methods (wmem_packet_scope,
wmem_file_scope, etc) in favour of passing them around in arguments
(or in pinfo, or something). This would let us drop a bunch of
in-
Sorry Pascal, I overlooked that you already mentioned this difference at the
end of your reply:
> I had the same idea in the past, mostly because of subtle bugs where
> Wireshark was using already freed packet memory because of the
> difference between packet and pool scopes (that is documented
Hi Evan and Pascal,
> > At a first glance, we already have pinfo->pool which maintains the
> > lifetime of the packet_info object. As far as I can reason, this is
> > almost/effectively the same as the existing wmem_packet_scope - it
> > gets cleaned up later in the dissection flow, but there's st
Hi Evan,
Le lun. 12 juil. 2021 à 17:52, Evan Huus a écrit :
> I've been thinking recently about starting the process of getting rid
> of the "global" wmem scope methods (wmem_packet_scope,
> wmem_file_scope, etc) in favour of passing them around in arguments
> (or in pinfo, or something). This w
I've been thinking recently about starting the process of getting rid
of the "global" wmem scope methods (wmem_packet_scope,
wmem_file_scope, etc) in favour of passing them around in arguments
(or in pinfo, or something). This would let us drop a bunch of
in-scope/out-of-scope tracking and assertio
16 matches
Mail list logo
