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
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
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
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
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-
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 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 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: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.
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
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
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:
>>
>> #
> 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
> 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
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
[ 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
16 matches
Mail list logo
