Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

[Bálint Réczey]

Hi Guy,

Guy Harris  ezt írta (időpont: 2023. dec. 21., Cs, 21:04):
>
> On Dec 21, 2023, at 6:51 AM, Bálint Réczey  wrote:
>
> > I'm not sure why libvirt dissector users should be "their users". In my 
> > eyes they are very much our users as well since they use Wireshark extended 
> > with the plugin and I'm happy that they get the best service.
>
> It appears that the protocol that the libvirt dissector handles is an ONC 
> RPC-based protocol, and that the dissector, for some unknown reason, has its 
> own XDR routines, rather than using the ones that come with Wireshark and are 
> used by the built-in dissectors for various ONC RPC-based protocols.
>
> Is there some compelling reason why we don't just implement a built-in 
> dissector for the libvirt protocol, using our built-in support for ONC 
> RPC-based protocols, and render the libvirt plugin unnecessary?

Yes, I believe. The protocol changes every few months and Wireshark's
implementation would be almost always outdated:
https://gitlab.com/libvirt/libvirt/-/issues/106#note_480339789

Cheers,
Balint

> (Speaking of ONC RPC-based protocols, it might also be nice if somebody 
> either 1) took the libvirt project's genxdrstub.pl Perl script and turned it 
> into a script that converts rpcgen specifications for ONC RPC-based protocols 
> into dissectors using our built-in ONC RPC support or 2) took Sun's rpcgen 
> itself and did the same?  If somebody went with 2), they should probably grab 
> a reasonably recent version of rpcgen, such as one from OpenSolaris - 
> probably the one in Illumos - rather than one from the 1980's-vintage 
> open-source ONC RPC release Sun put out, as the latter doesn't have support 
> for 64-bit integers.)
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

[Bálint Réczey]

Hi Roland,

Roland Knall  ezt írta (időpont: 2023. dec. 20., Sze,
20:44):
>
> We messed up in a sense, that we should have found an argument and final
position on API compatibility. Not that it did not work out well, but it
"happened" instead of being planned
>
> That was, what I meant with "messed up".

Ah, thanks, I misunderstood the "messed up" part.

>
> I read their argument and I still disagree. It might be the best for
their users, but we also facilitated that approach by our approach to the
whole issue.

I'm not sure why libvirt dissector users should be "their users". In my
eyes they are very much our users as well since they use Wireshark extended
with the plugin and I'm happy that they get the best service.

Cheers,
Balint

>
> Am Mi., 20. Dez. 2023 um 19:57 Uhr schrieb Bálint Réczey <
bal...@balintreczey.hu>:
>>
>> Roland Knall  ezt írta (időpont: 2023. dec. 20., Sze,
17:06):
>> >
>> > Ok, I am not ignoring those points, as I think those points are valid.
It makes sense, that building debian packages from the repository should
behave in the same way as it does with the overall projects. Now, one could
argue, that having multiple packages could have been avoided in the
beginning or it should be changed, that would be a valid discussion being
had, but I do not think it invalidates those points and arguments. Yes,
debian is different but it is also the base (through ubuntu) for the
majority of linux distributions as wells Microsofts own variety in wsl2 (at
least if you go with the default one), and therefore it should be
considered as such.
>> >
>> > The examples listed here are valid, although not very widely
distributed ones. Just because they are not distributed with a debian
distribution is not a counterargument to the update argument Balint raised.
I am also not certain, why arguing against that on the pure merit of not
being part of a distribution is a technical argument.
>> >
>> > The libvirt plugin is a valid example of where we messed up. And with
we I mean the whole project. We provided this path and we kept it
maintained for far too long, but it is here now and a solution needs to be
found. We started on that road with stating that we allow invalidating the
api in major version releases and also minor version releases to some
extend. The argument, that libvirt is still doing something they should not
be doing is valid. But the solution here is not hindering the
compatibility, but getting in touch with them and figuring out how to do it
properly together. We created this path, we should not destroy it but help
others find a safer route. And libvirt is indeed being used by quite a few
people.
>>
>> I generally agree with you on the other points, but why do you believe
>> we messed up? We allow and help external plugin development and did it
>> in a widely followed way of maintaining the shared library ABI and
>> headers. I think we did great in that regard and libvirt just
>> maintains an external plugin, the way we advertised to be possible. I
>> also think that there is no better way, but I'll be ready to be proven
>> wrong.
>>
>> We talked about the libvirt plugin and this is why I believe that the
>> status quo is the best for the users:
>>
https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1660815830
>>
>> I also reached out to them prior to our conversation and they
>> elaborated on their decision to ship the plugin separately and I'm
>> convinced that that's the best option of the users:
>> https://gitlab.com/libvirt/libvirt/-/issues/106#note_488155469
>>
>> Cheers,
>> Balint
>>
>> >
>> > As for the straw man argument, the Code of Conduct defines how
collaboration and social interaction should happen. As such, I do not see
this as a straw man argument but a valid reason, why Balint chose the paths
he chose in the past and why this package exists as it does now. In a
technical discussion it is as important to understand why somebody did
something as it is to listen to each others arguments. And this gives
reason to why the current situation is what it is, and should be validated
in choosing a solution for the future.
>> >
>> > kind regards
>> > Roland
>> >
>> > Am Mi., 20. Dez. 2023 um 16:32 Uhr schrieb João Valverde :
>> >>
>> >> Keep in mind I am just a user but I'm not one to skip a good technical
>> >> discussion.
>> >>
>> >> I'm ignoring your other points on purpose, there is only so much I can
>> >> handle in one sitting.
>> >>
>> >> On 20/12/23 13:24, Bálint Réczey wrote:
>> >> > Having

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

[Bálint Réczey]

Hi João,

On 2023. Dec 21., Thu at 12:02, João Valverde  wrote:

>
> On 20/12/23 23:20, Anders Broman wrote:
> > Hi,
> > To me it is a useful feature to be able to easily build .deb packages
> > and make repos to easily update and maintain wireshark across servers.
> > This is a feature I vote for us to keep regardless of any opinion on
> > how Debian build their packages. Maybe a Debian mailing list is a
> > better place to discuss their build system?
>
> I don't know what that has anything to do with what I said below but
> that is totally fine. I'm not against a Debian package. I'm against
> mirroring Debian in this project. I note you


The package is not an exact mirror of the one in Debian. I make changes in
Debian first targeting Debian unstable that has the latest packages and I
follow the latest best practices there.

The packaging scripts here target the broadest set of supported Debian an
Ubuntu releases to help installing it anywhere.
A good example is that Wireshark in unstable builds wit Qt6, while the
Debian scripts here use Qt5.

I cherry pick changes which I believe to be useful here. I noticed that
others updated build dependencies here earlier sometimes as Wireshark
started supporting building with them in master and I’m thankful for that.
Also thanks for other packaging related fixes.

I already explained in this thread why the package and file layout are the
same here as in Debian.

Cheers,
Balint

already asked me twice how
> the package could be made better, I answered both times (IMO) and you
> never replied back.
>
> > Just my 2 cents
> > Anders
> >
> > Den ons 20 dec. 2023 23:49João Valverde  skrev:
> >
> >
> >
> > On 20/12/23 22:35, Roland Knall wrote:
> > >
> > >> Am 20.12.2023 um 22:43 schrieb João Valverde :
> > >>
> > >> 
> > >>
> > >>> On 20/12/23 21:21, Roland Knall wrote:
> > >>>
> > > Am 20.12.2023 um 22:02 schrieb João Valverde :
> >  
> > 
> > > On 20/12/23 20:52, Roland Knall wrote:
> > >
> > >
> > > So people can link to our libraries to write other projets?
> > And expect it to work reliably? That is news to me. I have made
> > this question many times over the years but I guess I was not
> > worthy of a clear answer until now.
> > >
> > >>> I am not saying they should do it or that I appreciate it
> > happening. All I am saying is that it happens and is happening and
> > we did not put a stop to it in time. Should they expect it to be
> > reliable? Of course not as I answered also in other threads on
> > this matter. But at the same time I see no point in having them
> > hit a wall face on, rather work in such cases where we know about
> > it, to ensure them moving to a saner approach.
> > >> What?! I'm back to confused... So you don't like the situation,
> > you say. Here's a thought.. maybe if Debian didn't publish system
> > libraries in our name with these stupid symbol lists then people
> > wouldn't get the crazy idea they could use these libraries that
> > were published for this exact purpose and build their own software
> > on top of it and expect it to work reliable and not break every
> > other release, like most other non-Wireshark Debian libraries.
> > >>
> > >> I wonder what could be done about that. I guess Debian would
> > get that clue pretty darn quick if we weren't mirroring their
> > broken setup in our repository, thereby sanctioning it.
> > >>
> > >> I don't know, call me crazy. Or did I misunderstand again? Sure
> > seems complicated to get my head around this for such a simple
> > topic as is software release and distribution.
> > > Just a thought, libvirt was not created by debian but RedHat so
> > the state of debian packaging has nothing to do with them. Debians
> > package is merely moving their approach onto Debian, but the
> > decision to implement libvirts plugin in such a way had been done
> > by RedHats folks.
> >
> > And what such way is that?! I don't even know why libvirt keeps
> > coming
> > up in this discussion. They wrote a dissector plugin. That's
> > great. Good
> > for them. I don't upstream many of my plugins into Wireshark either.
> > This is something so banal that I am honestly confused why libvirt
> > keeps
> > coming up as a big boogaloo in this discussion.
> >
> > I ask again in all sincerity, because I could be misunderstanding,
> > what
> > is the difficulty created by the libvirt plugin and what does that
> > have
> > to do with Debian packaging?
> >
> >
> > >>
> >
>  ___
> > >> Sent via:Wireshark-dev mailing list
> > 
> > >> Archives: https://www.wireshark.org/lists/wireshark-dev
> > >> Unsubscribe:
> > 

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

[Bálint Réczey]

Roland Knall  ezt írta (időpont: 2023. dec. 20., Sze, 17:06):
>
> Ok, I am not ignoring those points, as I think those points are valid. It 
> makes sense, that building debian packages from the repository should behave 
> in the same way as it does with the overall projects. Now, one could argue, 
> that having multiple packages could have been avoided in the beginning or it 
> should be changed, that would be a valid discussion being had, but I do not 
> think it invalidates those points and arguments. Yes, debian is different but 
> it is also the base (through ubuntu) for the majority of linux distributions 
> as wells Microsofts own variety in wsl2 (at least if you go with the default 
> one), and therefore it should be considered as such.
>
> The examples listed here are valid, although not very widely distributed 
> ones. Just because they are not distributed with a debian distribution is not 
> a counterargument to the update argument Balint raised. I am also not 
> certain, why arguing against that on the pure merit of not being part of a 
> distribution is a technical argument.
>
> The libvirt plugin is a valid example of where we messed up. And with we I 
> mean the whole project. We provided this path and we kept it maintained for 
> far too long, but it is here now and a solution needs to be found. We started 
> on that road with stating that we allow invalidating the api in major version 
> releases and also minor version releases to some extend. The argument, that 
> libvirt is still doing something they should not be doing is valid. But the 
> solution here is not hindering the compatibility, but getting in touch with 
> them and figuring out how to do it properly together. We created this path, 
> we should not destroy it but help others find a safer route. And libvirt is 
> indeed being used by quite a few people.

I generally agree with you on the other points, but why do you believe
we messed up? We allow and help external plugin development and did it
in a widely followed way of maintaining the shared library ABI and
headers. I think we did great in that regard and libvirt just
maintains an external plugin, the way we advertised to be possible. I
also think that there is no better way, but I'll be ready to be proven
wrong.

We talked about the libvirt plugin and this is why I believe that the
status quo is the best for the users:
https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1660815830

I also reached out to them prior to our conversation and they
elaborated on their decision to ship the plugin separately and I'm
convinced that that's the best option of the users:
https://gitlab.com/libvirt/libvirt/-/issues/106#note_488155469

Cheers,
Balint

>
> As for the straw man argument, the Code of Conduct defines how collaboration 
> and social interaction should happen. As such, I do not see this as a straw 
> man argument but a valid reason, why Balint chose the paths he chose in the 
> past and why this package exists as it does now. In a technical discussion it 
> is as important to understand why somebody did something as it is to listen 
> to each others arguments. And this gives reason to why the current situation 
> is what it is, and should be validated in choosing a solution for the future.
>
> kind regards
> Roland
>
> Am Mi., 20. Dez. 2023 um 16:32 Uhr schrieb João Valverde :
>>
>> Keep in mind I am just a user but I'm not one to skip a good technical
>> discussion.
>>
>> I'm ignoring your other points on purpose, there is only so much I can
>> handle in one sitting.
>>
>> On 20/12/23 13:24, Bálint Réczey wrote:
>> > Having separate packages follows Debian packaging best practices and
>> > served external projects extending wireshark such as netexpect (
>> > https://tracker.debian.org/news/505793/accepted-netexpect-018-1-source-i386/
>>
>> I lookup up what netexpect is. Your link is from 2011. Actual link
>> (https://tracker.debian.org/pkg/netexpect) says "This package is not
>> part of any Debian distribution." OK... Starting strong there.
>>
>> > ) and the separately maintained libvirt dissector (
>> > https://packages.debian.org/unstable/libvirt-wireshark ).
>>
>> You keep coming back to the libvirt plugin. What do you expect to prove
>> with this? You really think maintaining separate Debian packages is a
>> benefit to a Wireshark plugin? I'm sorry, I don't know how to respond to
>> non-sensical statements. Do you want me to build the libvirt-wireshark
>> plugin against our RPM package just to put this argument to rest once
>> and for all?
>>
>>
>> > As I interpret our Code of Co

Re: [Wireshark-dev] Changes to the plugin registration API

[Bálint Réczey]

Hi Roland,

Roland Knall  ezt írta (időpont: 2023. dec. 4., H, 13:16):
>
> I do not think we need to revert the whole change. I actually like the way 
> the new version check is implemented and think it is beneficial to a lot of 
> users, because it will reduce the number of changes they have to make in 
> order to update their version.

While ABI stability is promised only between minor releases there is
tremendous value in long term API stability because it saves work for
people maintaining software relying on the API. For this reason I
strongly oppose changing the plugin registration API in a backward
incompatible manner unless it is really needed and is asked for by
heavy users of the API.

My recent experience here is limited to libvirt's plugin which I have
to get recompiled for every major Wireshark release. That
recompilation can't easily be avoided, since even the simplest plugins
link to libwsutil:

rbalint@air-m1:~$ otool -L
/Applications/Wireshark.app/Contents//PlugIns/wireshark/4-2/codecs/g711.so
/Applications/Wireshark.app/Contents//PlugIns/wireshark/4-2/codecs/g711.so:
@rpath/libwsutil.15.dylib (compatibility version 15.0.0, current
version 15.0.0)
@rpath/libglib-2.0.0.dylib (compatibility version 6801.0.0,
current version 6801.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1319.100.3)

This makes copying plugins across major releases unlikely to work, but
simple recompilations will most likely keep working as long as we
don't change the API much and in the past years we did quite well in
that regard.
To avoid mixing up ABI incompatible plugins the plugins we keep keep
plugins in major+minor release specific subdirs (.../4-2/... above)
and with the ABI stability promise between maintenance releases it is
simple, understandable and reliable.

Changing the API and filesystem layout significantly would also
require changes in many teaching materials and guides in addition to
generating work for every plugin maintained outside of our repository
and should happen only when there are clear benefits outweighing the
work imposed on others.
Adding new optional info to be provided by plugins via defining new
function calls in the plugin API is easy and I don't oppose that.
Plugin compatibility levels are already well defined, understood and
guarded by relying on the shared library ABI versioning.

The plugin registration changes that landed while the conversation
about them was still ongoing led to introduction of new plugin
compatibility versioning changes, triggered filesystem layout changes
and plugin naming changes while adding very little extra to make up
for breaking the pre-existing practice.

I propose returning to what worked well for many years and reverting
the API changes that were not adequately discussed beforehand to avoid
imposing unnecessary work on external plugin maintainers.
I've prepared an MR with the reverts at
https://gitlab.com/wireshark/wireshark/-/merge_requests/13747 .
It is marked as a draft to wait for the conclusion of _this_
discussion. If you would like to return to the well tested API and
filesystem layout and would like to land the revert please give a
thumbs up there.

If you would like to keep the landed changes please elaborate why, and
if you wish leave a thumbs down at the revert.

> But I do think the enforcement of licenses is a too strict reading of GPL v2. 
> Overmore it is a major change, and I think it should be avoided as it will 
> kill a lot of legitimate use-cases for Wireshark. I understand that we need 
> to be as open as possible, but this is actually killing the openess instead 
> of helping it.
>
> As much as it pains us, we must allow corporate users to maintain their own 
> plugin and manage it with future versions of Wireshark. Everything else is 
> not in the best interest of the application.

I personally don't feel much pain about letting corporate users
develop in-house plugins, because most of them are also the
corporations who let their employees contribute to Wireshark on their
paid time and maybe even support the Wireshark Foundation financially.
I see that as mutually beneficial.

I think we resolved the GPL question and there is no pressing need to
check the plugins' license, it was just based on an unfortunate
misunderstanding.

Cheers,
Balint




> Just my 2 cents
>
> Roland
>
> Am Mo., 4. Dez. 2023 um 13:12 Uhr schrieb Bálint Réczey 
> :
>>
>> João Valverde  ezt írta (időpont: 2023. dec. 4., H, 12:59):
>> >
>> >
>> >
>> > On 03/12/23 23:25, João Valverde wrote:
>> > > Hi,
>> > >
>> > > There are some changes in progress to the plugin registration API that
>> > > break compatibility and require manual intervention from plugin
>> > > authors maintaining plugins out-of-tree. These changes are rather
>> > > minor

Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

[Bálint Réczey]

Hi,

João Valverde  ezt írta (időpont: 2023. nov. 27., H, 21:42):
>
>
>
> On 27/11/23 16:26, Jeff Morriss wrote:
> > On Wed, Nov 22, 2023 at 11:54 AM João Valverde  wrote:
> >
> >
> > On 22/11/23 15:37, John Thacker wrote:
> >> On Wed, Nov 22, 2023 at 9:40 AM João Valverde  wrote:
> >>
> >>
> >> There are a myriad issues I have touched upon. To recap, in
> >> my opinion, if we want to provide public shared libraries
> >> (libwireshark, wiretap, wsutil... for what I don't know) we
> >> should do a better job of that collectively as a project. If
> >> we don't want to do that we should kill the Debian package
> >> inanity.
> >>
> >> A third alternative is just to keep the status quo and I'll
> >> try to avoid this subject entirely because of how much it
> >> bothers me to just ignore all these technical issues.
> >>
> >>
> >> My understanding of the Debian packaging scripts (and similar for
> >> the RPM package) use case is that people might be running one of
> >> those distributions and want to upgrade Wireshark on their system
> >> using their distribution's native package manager by taking
> >> either a git repository or a tarball and building a package that
> >> they can upgrade their distribution-provided package to.
> >>
> >> That isn't necessarily to add custom dissectors and provide
> >> public shared libraries, though it could be. Oftentimes it's as
> >> simple as "my distribution is capable of compiling 3.6.x or
> >> later, but for stability reasons it's still shipping 2.6.x
> >> (Debian buster/oldstable, RHEL 8 and clones)," and someone wants
> >> to update wireshark without any of their own changes, just
> >> without upgrading their distribution. It's handy to be able to
> >> accommodate that if possible.
> >
> > Thanks for the feedback. Let me try to break down my response to that:
> >
> > 1. I think spending resources on distro packaging is unwise in
> > general. "Make install" works fine and there are great maintainers
> > already doing that work for Linux distributions. RPM is just
> > low-effort low-intrusion enough that it doesn't bother me to
> > divert from other tasks to work on it when I have to.
> >
> >
> > I used to maintain a custom Wireshark build.  The packaging stuff was
> > invaluable for that: it allowed me to compile (and easily package)
> > once and push the resulting RPMs to hundreds of systems.  "make
> > install" would not have worked for me as the end (user) systems were
> > not capable of compiling Wireshark.
> >
> > I also, for a while, used our RPM stuff as an upstream example for
> > Fedora/Red Hat to improve their packaging, including (IIRC) bringing
> > in all the freedesktop integration stuff.  It was a lot easier to
> > check that stuff into Wireshark and point them to it than try to do
> > all the work in their world/repo (which is unfamiliar to me).
> >
>
> I was addressing the user-wants-to-build-locally use case with the "make
> install" comment.
>
> To address your use-case:
>
> 1. Someone whose job is to maintain a custom build for a medium/large
> organization does not depend on us to create a package, although it can
> help of course. At the end of the day resources are limited and need to
> be prioritized for a volunteer project. Like I said, RPM doesn't bother
> me, it rarely gets in my way or demands much of my time.
>
> 2. If someone on the Wireshark team wants to assume the package
> maintainer role that could work if they are responsive and not putting
> some distribution's priorities above our own.

I tried to assess the amount of work required by the presence of the
Debian packaging scripts in the repository.
This is what I found covering roughly one year of development in the
master branch between branching off the 4.0 and 4.2 releases:

$ git merge-base origin/release-4.2 origin/master | xargs git describe
v4.1.1rc0-386-geb539196a9
$ git merge-base origin/release-4.2 origin/release-4.0  | xargs git describe
v3.7.3rc0-146-g7d583e1340
$ git log --oneline v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 | wc -l
3925
$ git log --oneline
v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
packaging/debian/ | wc -l
64
$ git log --oneline
v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
packaging/debian/*.symbols | wc -l
50

1.6% of all the commits touched the packaging scripts. Most of the
1.6% is updating the symbols files when the shared library ABI changed
and I did not consider that excessive, but seeing the complaints I've
switched the packaging to not require symbols file updates in
https://gitlab.com/wireshark/wireshark/-/merge_requests/13385 .

The remaining Debian packaging script 14 updates accidentally matches
the number of updates to the RPM scripts and makes up 0.3% of all
Wireshark commits in the analyzed history:
$ git log --oneline

Re: [Wireshark-dev] Changes to the plugin registration API

[Bálint Réczey]

João Valverde  ezt írta (időpont: 2023. dec. 4., H, 12:59):
>
>
>
> On 03/12/23 23:25, João Valverde wrote:
> > Hi,
> >
> > There are some changes in progress to the plugin registration API that
> > break compatibility and require manual intervention from plugin
> > authors maintaining plugins out-of-tree. These changes are rather
> > minor and concern only plugin registration, not other APIs accessible
> > to plugins.
> >
> > See MR 13524:
> > https://gitlab.com/wireshark/wireshark/-/merge_requests/13524
> >
> > Changes required are rewriting the registration code (very easy to do
> > [1]) and declare (using a C enum) that the plugin is released either
> > under GPLv2 or later, or a GPLv2 compatible license. The other changes
> > to the ABI version number are
>
> The choice of the word "released" here was unfortunate, because it may
> imply distribution. Please consider "licensed" instead.
>
> The license declaration field just affirms what was already implicit:
> Wireshark plugins must use licensing terms compatible with the GPL
> version 2, so there is no policy change there.

GPL allows linking and using GPL-licensed software with
non-GPL-licensed software locally. This is an important use case of
many Wireshark users who do not wish releasing their plugins and your
change broke that. Please revert it.

>
> > currently not relevant to plugin authors (no policy change is
> > implied), it just uses less boilerplate with macros.
> >
> > This should improve the plug-in experience for both developers and
> > users and may improve compatibility in the future.


> >
> > Comments welcome.
> >
> > Regards,
> >
> > João
> >
> > [1]https://gitlab.com/wireshark/wireshark/-/commit/90b16b40921b737aadf9186685d866fd80e37ee6#4a1fe9011e8240918e5fc6230c0bcd2e4d3b9c34
> >
> > ___
> >
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Changes to the plugin registration API

[Bálint Réczey]

On 2023. Dec 4., Mon at 10:02, João Valverde  wrote:

> Hi,
>
> The GPL never allowed for that, as far as I know. See:
>
> https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
>
> In this case Wireshark is a library for plug-ins.
>
> What you can do is not distribute the (private-use) plug-in, and
> therefore you do not have a requirement to make the source available.
> You cannot use a GPL-incompatible license to link to Wireshark, i.e load
> a plug-in. That is a violation of the license terms.
>
> Note that the GPL terms apply to the whole combined work, even though
> the plug-in may be using some other (GPL-compatible) FOSS license.
>
> So it was already not allowed and that is not a change in policy.


Please read the GPL license more carefully and maybe related publications.
You seem to overstate GPL’s restrictions. The current practice is fine
AFAIK.



>
> Regards,
>
> João
>
> On 04/12/23 06:30, Anders Broman wrote:
> > Hi,
> > Does this mean that we are no longer allowing private closed source
> > plug-ins not distributed outside of companies?
> >
> > If so isn't that a rather big change of policy?
> >
> > Best regards
> > Anders
> >
> > Den mån 4 dec. 2023 00:26João Valverde  skrev:
> >
> > Hi,
> >
> > There are some changes in progress to the plugin registration API
> > that
> > break compatibility and require manual intervention from plugin
> > authors
> > maintaining plugins out-of-tree. These changes are rather minor and
> > concern only plugin registration, not other APIs accessible to
> > plugins.
> >
> > See MR 13524:
> > https://gitlab.com/wireshark/wireshark/-/merge_requests/13524
> >
> > Changes required are rewriting the registration code (very easy to do
> > [1]) and declare (using a C enum) that the plugin is released either
> > under GPLv2 or later, or a GPLv2 compatible license. The other
> > changes
> > to the ABI version number are currently not relevant to plugin
> > authors
> > (no policy change is implied), it just uses less boilerplate with
> > macros.
> >
> > This should improve the plug-in experience for both developers and
> > users
> > and may improve compatibility in the future.
> >
> > Comments welcome.
> >
> > Regards,
> >
> > João
> >
> > [1]
> https://gitlab.com/wireshark/wireshark/-/commit/90b16b40921b737aadf9186685d866fd80e37ee6#4a1fe9011e8240918e5fc6230c0bcd2e4d3b9c34
> >
>  ___
> > Sent via:Wireshark-dev mailing list  >
> > Archives: https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >
> >  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
> >
> >
> >
> ___
> > Sent via:Wireshark-dev mailing list 
> > Archives:https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> >   mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main repository

[Bálint Réczey]

Hi All,

João shared his opinion about the project's commitment to maintain the
packaging/debian/ in the project's repository:

https://gitlab.com/wireshark/wireshark/-/commit/79da670bd1b4f91eebee5c96b19eaf1f33c94777#note_1656501952

I believe the current practice is reasonable and beneficial enough for
many parties to warrant the work, but I could be wrong.

Probably the most important question is if there is anyone relying on
the packaging scripts there. If you are, please speak up otherwise the
directory may be dropped.

Comments are welcome.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

[Bálint Réczey]

João Valverde  ezt írta (időpont: 2022. jan. 21., P, 11:17):
>
>
>
> On 21/01/22 09:44, Bálint Réczey wrote:
> > Hi João,
> >
> > João Valverde  ezt írta (időpont: 2022. jan. 21., P, 1:14):
> >>
> >>
> >> On 20/01/22 12:41, Bálint Réczey wrote:
> >>> Hi All,
> >>>
> >>> João shared his opinion about the project's commitment to maintain
> >>> stable shared library ABI within stable branches:
> >>> https://gitlab.com/wireshark/wireshark/-/issues/17822
> >>>
> >>> I believe the current practice is reasonable and beneficial enough for
> >>> many parties to warrant the work, but I could be wrong.
> >>>
> >> I agree the current practice is reasonable and beneficial, and it is
> >> currently documented in README.Developer[1], chapter 7.3, to the best of
> >> my understanding and ability.
> > OK, great to hear that from you. I got the impression from the gitlab
> > comments that you had a different view.
> >
> >> Do you have changes you'd like to propose? I'll gladly go over those.
> > I'm happy with the the project's commitment to ABI stability and agree
> > with Gerald's proposal of trying to revive the abi-complicance-checker
> > test to help him in the final release checks. I may find time to
> > restore the changes after this discussion is settled.
> >
> > Since you are asking, I'd very much welcome less hostility from your
> > side than what I observed in [2] when I reported the ABI breakage.
> >
> > What triggered my email was that after I reported the ABI breakage you
> > made in the stable branch you refused to own and fix it [3] and even
> > after Gerald kindly stepped in with the fix [4] you kept arguing ([5]
> > [6] ...) and this made me tired and wondering if you really represent
> > the project's opinion as you seemed to believe.
>
> I don't mind the email. We do disagree on many things and what I said on
> the Gitlab issue is exactly what I meant. My lack of patience with you
> is entirely justified.
>
> >
> >> What I won't do, however, is maintain your package for you.
> > I maintain the package in Debian for the users and not particularly
> > for myself since I'm not using Wireshark in my profession as I used to
> > do.
> > In general I'm happy to accept help, but I think I've never asked for
> > your help specifically for that package and I note that I should not
> > ask in  the future either.
> >
> > The Debian packaging in the upstream repository, i.e. [7] serves a
> > different set of users, those who want to be closer to the latest
> > development of Wireshark and the packaging scripts are kept a bit
> > simpler. I intentionally don't make too many changes there to let the
> > Wireshark project members set the direction and the changes there go
> > through the regular local review process. I believe the packaging in
> > itself is useful and the .symbols files help noticing ABI changes.
> >
>
> I strongly believe the upstream Debian package to be a detriment to the
> project, and not in the interest of users either. I will share my
> experience as a user. I  had to build the Wireshark Debian package to
> fix something or other. I looked up online the incantation to use and it
> seemed to work ok. After it was done building it spewed a bunch of files
> all over my filesystem. Many different packages. I tried installing them
> one by one and didn't succeed. I tried all at once and didn't succeed
> either. I had to guess the order necessary to get it to install.
> Afterward there was some apt conflict with the Wireshark package in the
> official repos. I tried uninstalling the packages I had manually
> installed and broke the package manager with some dependency issue.
> After half an hour trying to fix it I gave up. The end.

Before installing the upstream packages it is recommended to remove
all installed packages generated from Debian's official wireshark
source package because incompatibilities can't be prevented otherwise.
When testing new builds I do that and just install all built .deb-s.

> There is no good reason for this package to exist upstream in its
> current state, nor does Debian recommend that practice in general, AFAIK.

Debian many years ago used to _not_ recommend upstreams to to keep
packaging scripts in their main repo because Debian's tools could not
clean up the debian/ dir automatically. Now this is solved in the
tools, thus upstreams are free to keep or not keep Debian packaging in
their source tree.

As I wrote earlier I believe the upstream debian/ dir helps in
monitoring ABI stability, but I don't insist keeping it if the project
decides to remove it.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

[Bálint Réczey]

Hi Roland,

Roland Knall  ezt írta (időpont: 2022. jan. 21., P, 11:48):
>
> May I suggest that we focus on the discussion at hand here. The discussion 
> about the package itself seems to be better suited for the issue list 
> specific for that package, as is the purpose for that list.
>
> The issue here is, that with change 
> https://gitlab.com/wireshark/wireshark/-/merge_requests/5318 version changes 
> where backported in 3.6, which are only meant to be in 3.7 and beyond (hence 
> the reference in libwireshark0.symbols). Regardless of what some may think of 
> the ensuing discussion, as a general rule we do not introduce library changes 
> within release branches. For that reason alone (and only for that reason) I 
> would say that the change needs to be reversed.
>
> Now for the validity of the overall change, I do think it is valid and makes 
> absolute sense. I also think that external programs should not expect huge 
> stability for our APIs as they may change anytime between major releases. If 
> it is within our scope and reason to avoid such changes or dependencies we 
> should try to do so. I also do think that ABI compatibility should not be set 
> in stone.

I fully agree with and support the current practice of allowing ABI
breakages between major releases and those are well handled by bumping
the major SO version. My bug report was about breaking the ABI between
3.6.0 and 3.6.1 and somehow this escalated.

Cheers,
Balint

>
> kind regards
> Roland
>
> Am Fr., 21. Jan. 2022 um 11:17 Uhr schrieb João Valverde :
>>
>>
>>
>> On 21/01/22 09:44, Bálint Réczey wrote:
>> > Hi João,
>> >
>> > João Valverde  ezt írta (időpont: 2022. jan. 21., P, 1:14):
>> >>
>> >>
>> >> On 20/01/22 12:41, Bálint Réczey wrote:
>> >>> Hi All,
>> >>>
>> >>> João shared his opinion about the project's commitment to maintain
>> >>> stable shared library ABI within stable branches:
>> >>> https://gitlab.com/wireshark/wireshark/-/issues/17822
>> >>>
>> >>> I believe the current practice is reasonable and beneficial enough for
>> >>> many parties to warrant the work, but I could be wrong.
>> >>>
>> >> I agree the current practice is reasonable and beneficial, and it is
>> >> currently documented in README.Developer[1], chapter 7.3, to the best of
>> >> my understanding and ability.
>> > OK, great to hear that from you. I got the impression from the gitlab
>> > comments that you had a different view.
>> >
>> >> Do you have changes you'd like to propose? I'll gladly go over those.
>> > I'm happy with the the project's commitment to ABI stability and agree
>> > with Gerald's proposal of trying to revive the abi-complicance-checker
>> > test to help him in the final release checks. I may find time to
>> > restore the changes after this discussion is settled.
>> >
>> > Since you are asking, I'd very much welcome less hostility from your
>> > side than what I observed in [2] when I reported the ABI breakage.
>> >
>> > What triggered my email was that after I reported the ABI breakage you
>> > made in the stable branch you refused to own and fix it [3] and even
>> > after Gerald kindly stepped in with the fix [4] you kept arguing ([5]
>> > [6] ...) and this made me tired and wondering if you really represent
>> > the project's opinion as you seemed to believe.
>>
>> I don't mind the email. We do disagree on many things and what I said on
>> the Gitlab issue is exactly what I meant. My lack of patience with you
>> is entirely justified.
>>
>> >
>> >> What I won't do, however, is maintain your package for you.
>> > I maintain the package in Debian for the users and not particularly
>> > for myself since I'm not using Wireshark in my profession as I used to
>> > do.
>> > In general I'm happy to accept help, but I think I've never asked for
>> > your help specifically for that package and I note that I should not
>> > ask in  the future either.
>> >
>> > The Debian packaging in the upstream repository, i.e. [7] serves a
>> > different set of users, those who want to be closer to the latest
>> > development of Wireshark and the packaging scripts are kept a bit
>> > simpler. I intentionally don't make too many changes there to let the
>> > Wireshark project members set the direction and the changes there go
>> > through the regular local review process. I believe the packaging in
>> &

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

[Bálint Réczey]

João Valverde  ezt írta (időpont: 2022. jan. 21., P, 1:29):
>
>
>
> On 20/01/22 21:24, Bálint Réczey wrote:
> > Hi Guy,
> >
> > Guy Harris  ezt írta (időpont: 2022. jan. 20., Cs, 
> > 21:52):
> >> On Jan 20, 2022, at 12:34 PM, Gerald Combs  wrote:
> >>
> >>> Q: Should *wsutil* be part of that stable ABI?
> >>>
> >>> Debian, Ubuntu and (according to rpmfind.net) OpenSuSE and Mageia treat 
> >>> it as such. It would be helpful to know what non-Wireshark packages 
> >>> depend on wsutil in those distributions and elsewhere.
> >> ...and, if there are any, to know *why*.
> > It seems libvirt's plugin needs wmem_alloc(), for example:
> > https://gitlab.com/wireshark/wireshark/-/issues/17889
>
> How is that relevant?
>
> The answer to the question that was asked is: exactly zero Debian
> packages have a dependency on your libwsutil/libwireshark/libwiretap
> packages.

In gitlab issue I already mention libvirt as a packaged thus I had the
impression that this one was covered:
https://gitlab.com/wireshark/wireshark/-/issues/17822#note_815677078

It is factually incorrect to state that nothing depends on our
libraries in Debian:

root@73c5830ef791:/# apt-cache rdepends libwireshark14
libwireshark14
Reverse Depends:
...
  libvirt-wireshark
root@73c5830ef791:/# cat /etc/issue
Debian GNU/Linux 11 \n \l

root@b396a73800b0:/# apt-cache rdepends libwireshark15
libwireshark15
Reverse Depends:
...
  libvirt-wireshark
root@b396a73800b0:/# cat /etc/issue
Debian GNU/Linux bookworm/sid \n \l

# apt-cache show libvirt-wireshark
Package: libvirt-wireshark
Source: libvirt
...
Description: Wireshark dissector for the libvirt protocol

I'm not sure how you checked, but this is what I saw on current stable and sid.

> If you want to see what a properly packaged non-trivial application for
> Debian looks like check out Geany[1] for example. It also uses shared
> libraries internally and has a plugin system.

Generally I'm open to learn new things, but after not being able to
find reverse dependencies of libwireshark* I hope you don't mind that
I take your advice on packaging with a grain of salt.

From Geany's description:

About - Geany is a small and lightweight integrated development
environment. It was developed to provide a small and fast IDE, which
has only a few dependencies from other packages. Another goal was to
be as independent as possible from a special Desktop Environment like
KDE or GNOME. So it is using only the GTK+ toolkit and therefore you
need only the GTK+ runtime libraries to run Geany.

As you can see Geany's goals are very different from Wireshark's and
Geany not providing shared libraries aligns with having minimal
dependencies.

Speaking of packaging non-trivial applications I maintained systemd
and glibc among other things in Ubuntu in the last few years thus I
have some experience in the area.

> > IMO it is easier mentally to have a single library ABI policy because
> > we ship only public libraries. Having a more relaxed private shared
> > library policy would make it easier to make mistakes.
>
> I have no idea what you are trying to say here. The libraries were not
> intended to be public until you stepped in, by the way.

I'm wondering if others did understand what I tried to say here.

As you pointed out in [2] there were recurring queries to make the
then private libraries more widely available and I accept the credit
or blame to help a lot in making the ABI stable and available for
external projects.

> > Also if libwsutil (with wmem_alloc) became private in 3.6.x then
> > libvirt had a much harder time continuing the maintenance of their
> > plugin starting with 3.6.0.
>
> No. Nobody said anything about 3.6.x and none of that is true.

This was a hypothetical example of what would happen if we moved
libwsutil to a private library location with no ABI stability promise.
And wmem_alloc did move to libwsutil in [3].

Thanks,
Balint

> [1] https://salsa.debian.org/geany-team/geany
[2] https://gitlab.com/wireshark/wireshark/-/issues/17822#note_815838497
[3] 
https://gitlab.com/wireshark/wireshark/-/commit/7f9c1f5f92c131354fc8b2b88d473706786064c0
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

[Bálint Réczey]

Hi João,

João Valverde  ezt írta (időpont: 2022. jan. 21., P, 1:14):
>
>
>
> On 20/01/22 12:41, Bálint Réczey wrote:
> > Hi All,
> >
> > João shared his opinion about the project's commitment to maintain
> > stable shared library ABI within stable branches:
> > https://gitlab.com/wireshark/wireshark/-/issues/17822
> >
> > I believe the current practice is reasonable and beneficial enough for
> > many parties to warrant the work, but I could be wrong.
> >
>
> I agree the current practice is reasonable and beneficial, and it is
> currently documented in README.Developer[1], chapter 7.3, to the best of
> my understanding and ability.

OK, great to hear that from you. I got the impression from the gitlab
comments that you had a different view.

> Do you have changes you'd like to propose? I'll gladly go over those.

I'm happy with the the project's commitment to ABI stability and agree
with Gerald's proposal of trying to revive the abi-complicance-checker
test to help him in the final release checks. I may find time to
restore the changes after this discussion is settled.

Since you are asking, I'd very much welcome less hostility from your
side than what I observed in [2] when I reported the ABI breakage.

What triggered my email was that after I reported the ABI breakage you
made in the stable branch you refused to own and fix it [3] and even
after Gerald kindly stepped in with the fix [4] you kept arguing ([5]
[6] ...) and this made me tired and wondering if you really represent
the project's opinion as you seemed to believe.

> What I won't do, however, is maintain your package for you.

I maintain the package in Debian for the users and not particularly
for myself since I'm not using Wireshark in my profession as I used to
do.
In general I'm happy to accept help, but I think I've never asked for
your help specifically for that package and I note that I should not
ask in  the future either.

The Debian packaging in the upstream repository, i.e. [7] serves a
different set of users, those who want to be closer to the latest
development of Wireshark and the packaging scripts are kept a bit
simpler. I intentionally don't make too many changes there to let the
Wireshark project members set the direction and the changes there go
through the regular local review process. I believe the packaging in
itself is useful and the .symbols files help noticing ABI changes.

Cheers,
Balint

[2] https://gitlab.com/wireshark/wireshark/-/issues/17822
[3] https://gitlab.com/wireshark/wireshark/-/issues/17822#note_811782349
[4] https://gitlab.com/wireshark/wireshark/-/issues/17822#note_815667191
[5] https://gitlab.com/wireshark/wireshark/-/issues/17822#note_815684186
[6] https://gitlab.com/wireshark/wireshark/-/issues/17822#note_815838497
[7] https://gitlab.com/wireshark/wireshark/-/commits/master/debian
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Future of Wireshark's shared library ABI stability

[Bálint Réczey]

Hi Guy,

Guy Harris  ezt írta (időpont: 2022. jan. 20., Cs, 21:52):
>
> On Jan 20, 2022, at 12:34 PM, Gerald Combs  wrote:
>
> > Q: Should *wsutil* be part of that stable ABI?
> >
> > Debian, Ubuntu and (according to rpmfind.net) OpenSuSE and Mageia treat it 
> > as such. It would be helpful to know what non-Wireshark packages depend on 
> > wsutil in those distributions and elsewhere.
>
> ...and, if there are any, to know *why*.

It seems libvirt's plugin needs wmem_alloc(), for example:
https://gitlab.com/wireshark/wireshark/-/issues/17889

IMO it is easier mentally to have a single library ABI policy because
we ship only public libraries. Having a more relaxed private shared
library policy would make it easier to make mistakes.

Also if libwsutil (with wmem_alloc) became private in 3.6.x then
libvirt had a much harder time continuing the maintenance of their
plugin starting with 3.6.0.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Future of Wireshark's shared library ABI stability

[Bálint Réczey]

Hi All,

João shared his opinion about the project's commitment to maintain
stable shared library ABI within stable branches:
https://gitlab.com/wireshark/wireshark/-/issues/17822

I believe the current practice is reasonable and beneficial enough for
many parties to warrant the work, but I could be wrong.

Comments are welcome.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Debianbuild fails on Ubuntu 18.04

[Bálint Réczey]

Hi Anders,

Anders Broman via Wireshark-dev  ezt írta
(időpont: 2021. okt. 20., Sze, 11:24):
>
> Hi,
>
> I can no longer create a debian package on Ubuntu 18.04...

The build fails due to a debhelper bug.
I've submitted the workaround at
https://gitlab.com/wireshark/wireshark/-/merge_requests/4755 .

Cheers,
Balint


>
>
> Best regards
>
> Anders
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] G729

[Bálint Réczey]

Hi Jaap,

Thanks for the heads up!:
https://salsa.debian.org/debian/wireshark/-/commit/4f3b519334121ee8115f255d21c22f305e233cc2

Cheers,
Balint

Jaap Keuter  ezt írta (időpont: 2020. dec. 7., H, 12:04):
>
> FYI, it seems to have finally happened, bcg729 has landed in Debian testing.
>
> ---8<---
> From: Debian FTP Masters 
> To: 785480-cl...@bugs.debian.org
> Subject: Bug#785480: fixed in bcg729 1.1.1-1
> Date: Sun, 06 Dec 2020 13:00:08 +
> Source: bcg729
> Source-Version: 1.1.1-1
> Done: Victor Seva 
>
> We believe that the bug you reported is fixed in the latest version of
> bcg729, which is due to be installed in the Debian FTP archive.
> ---8<---
>
> This opens the path to having G.729 capability in regular Debian and 
> derivatives builds.
>
> Jaap
>
> On 6 Aug 2017, at 10:47, Jaap Keuter  wrote:
>
> Hi  Dario,
>
> I’ve already posted a note to Debian Bug 785480 ITP: bcg729 -- ITU G.729 
> Annex A compatible audio codec 
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785480) to make them aware 
> of the recent Wireshark developments in this matter. Have a look there what’s 
> going on with this packaging.
>
> Thanks,
> Jaap
>
>
>
> On 5 Aug 2017, at 18:32, Dario Lombardo  wrote:
>
> I've noticed that cmake shows me
>
> -- The following OPTIONAL packages have not been found:
>
>  * BCG729 , G.729 decoder , 
> 
>Support for G.729 codec in RTP player
>
> Does anyone know which package in ubuntu/debian contains it?
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Git tagging scheme

[Bálint Réczey]

Hi Gerald,

I noticed that there is no wireshark-3.0.0 tag in the repository.
Could you please create it?

In the Debian package the debian/watch file monitors the
wireshark-N.N.N tags for new releases.
I found the establisted practice of tagging final releases as
wireshark-.* and RC-s and similar releases with v.* only very useful,
please continue doing so!

Maybe the practice could be mentioned in
https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcGitRepository.html,
too, if we keep it.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Ubuntu PPAs

[Bálint Réczey]

2017-03-14 14:28 GMT+01:00 Peter Wu <pe...@lekensteyn.nl>:
> On Tue, Mar 14, 2017 at 12:29:24AM +0100, Bálint Réczey wrote:
>> Hi,
>>
>> I have created a separate PPA for backported dependencies of Wireshark:
>> https://launchpad.net/~wireshark-dev/+archive/ubuntu/wireshark-deps
>>
>> This would help people running internal builds of Wireshark. (Hi
>> Anders, sorry for the delay ;-))
>>
>> I plan removing the dependencies from the wireshark-dev/stable PPA to
>> remove redundancy:
>> https://launchpad.net/~wireshark-dev/+archive/ubuntu/stable
>
> Is it possible to express dependencies between PPAs? Otherwise you would
> run into missing dependency issues I think?

Yes, I have already set the dependency relation for the PPAs, but I
would like to give
them a try before I remove the redundant packages from wireshark-dev/stable.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Ubuntu PPAs

[Bálint Réczey]

Hi,

I have created a separate PPA for backported dependencies of Wireshark:
https://launchpad.net/~wireshark-dev/+archive/ubuntu/wireshark-deps

This would help people running internal builds of Wireshark. (Hi
Anders, sorry for the delay ;-))

I plan removing the dependencies from the wireshark-dev/stable PPA to
remove redundancy:
https://launchpad.net/~wireshark-dev/+archive/ubuntu/stable

I also plan creating a PPA for nightly builds for latest Ubuntu LTS
release (16.04 at the moment).

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Bálint Réczey]

Hi,

2017-02-11 22:44 GMT+01:00 Peter Wu :
> On Sat, Feb 11, 2017 at 08:54:39PM +, João Valverde wrote:
> [..]
>> I think a small abstraction layer above the lower-level crypto routines,
>> whatever those may be (libgcrypt, nettle, home-grown - yuck), would be a
>> useful thing to have. It would accomplish two things:
>>
>> 1. Easily change dependencies without having to change dissector code.
>>
>> 2. Disable crypto in a saner way and keep the dependency optional, without
>> having to use #ifdefs all over the place (just one place in fact). Example:
>>
>>   int ws_aes_decrypt(...) {
>>   #ifdef HAVE_AES_DEPENDENCY
>>  err = aes_decrypt(...);
>>  if (err == AES_OK) {
>>   return WS_CRYPTO_OK;
>>  } else {
>> ...
>>  }
>>   #else
>>  return WS_CRYPTO_DISABLED;
>>   #endif
>>   }
>>
>> Then of course require crypto consumers (dissectors and whatever else) to
>> handle the WS_CRYPTO_DISABLED case as appropriate.
>
> Disabling is an option if you want to make the crypto library optional,
> but the vast majority of the files/functions are hash functions (md5 is
> used for example in editcap.c for duplicate detection). Since you need a
> crypto library for the hash functions, you get decryption algorithms
> like AES for free. (Unless you want to keep the bundled algorithms... I
> would rather not).
>
> At this moment I don't know how the end result looks like. Maybe after
> actually looking at the files/functions, we'll see whether an extra
> abstraction is worth it or not.

+1 for going without a new layer of indirections.
Making libgcrypt mandatory is easy and every level of indirection make
understanding the code harder which is a source of bugs.

If we ever feel dropping libgcrypt necessary we can add the new layer.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Bálint Réczey]

Hi All,

2017-02-09 11:34 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
> Hi Guy,
>
> 2017-02-08 19:51 GMT+01:00 Guy Harris <g...@alum.mit.edu>:
>> On Feb 8, 2017, at 5:40 AM, Peter Wu <pe...@lekensteyn.nl> wrote:
>>
>>> I did not expect Libgcrypt to consume entropy when it is just doing
>>> decryption.
>>
>> I'm concerned with consuming CPU and wall-clock time - i.e., slowing *shark 
>> startup - not entropy.
>
> perf would show that.
>
> rbalint@chaos:~/Downloads$ cat exit.lua
> os.exit(1)
> rbalint@chaos:~/Downloads$ wireshark -X lua_script:exit.lua
> rbalint@chaos:~/Downloads$ perf record -g -- wireshark -X lua_script:exit.lua
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.249 MB perf.data (~10883 samples) ]
> rbalint@chaos:~/Downloads$ perf report --sort comm,dso
> +   58.47% 0.00%wireshark  [unknown]
> +   34.86%15.55%wireshark  libQt5Gui.so.5.3.2
> +   21.56%20.78%wireshark  libQt5Widgets.so.5.3.2
> +   11.88% 8.99%wireshark  libc-2.19.so
> +9.50% 9.42%wireshark  libglib-2.0.so.0.4800.0
> +8.90% 7.35%wireshark  libwireshark.so.8.1.2
> +8.75% 8.75%wireshark  [kernel.kallsyms]
> +8.06% 7.51%wireshark  libQt5Core.so.5.3.2
> +7.12% 3.97%wireshark  ld-2.19.so
> +5.45% 5.45%wireshark  libfontconfig.so.1.8.0
> +5.33% 5.33%wireshark  libz.so.1.2.8
> +1.75% 1.75%wireshark  libpng12.so.0.50.0
> +1.29% 1.29%  QThread  [kernel.kallsyms]
> +1.15% 1.13%wireshark  i965_dri.so
> +0.82% 0.13%wireshark  wireshark
> +0.50% 0.50%wireshark  libfreetype.so.6.11.1
> +0.46% 0.15%wireshark  libX11.so.6.3.0
> +0.40% 0.40%wireshark  libharfbuzz.so.0.935.0
> +0.30% 0.30%wireshark  libexpat.so.1.6.0
> +0.28% 0.00%wireshark  libnl-genl-3.so.200.19.0
> +0.28% 0.16%wireshark  libqxcb.so
> +0.20% 0.20%wireshark  libnettle.so.4.7
> +0.16% 0.00%  QXcbEventReader  [unknown]
> +0.16% 0.16%  QXcbEventReader  [kernel.kallsyms]
> +0.16% 0.03%  QXcbEventReader  libpthread-2.19.so
> +0.16% 0.16%wireshark  liblua5.2.so.0.0.0
> +0.15% 0.00%wireshark  libdl-2.19.so
> +0.15% 0.08%wireshark  libpthread-2.19.so
>
> I don't see anything related to that.

Seeing the Qt libs made me curious and ran another test on Debian
Jessie with packaged 2.2.2 :
rbalint@chaos:~/Downloads$ time wireshark-gtk -X lua_script:exit.lua

real0m0.304s
user0m0.244s
sys0m0.044s
rbalint@chaos:~/Downloads$ time wireshark -X lua_script:exit.lua

real0m0.906s
user0m0.556s
sys0m0.128s

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Bálint Réczey]

Hi Guy,

2017-02-08 19:51 GMT+01:00 Guy Harris :
> On Feb 8, 2017, at 5:40 AM, Peter Wu  wrote:
>
>> I did not expect Libgcrypt to consume entropy when it is just doing
>> decryption.
>
> I'm concerned with consuming CPU and wall-clock time - i.e., slowing *shark 
> startup - not entropy.

perf would show that.

rbalint@chaos:~/Downloads$ cat exit.lua
os.exit(1)
rbalint@chaos:~/Downloads$ wireshark -X lua_script:exit.lua
rbalint@chaos:~/Downloads$ perf record -g -- wireshark -X lua_script:exit.lua
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.249 MB perf.data (~10883 samples) ]
rbalint@chaos:~/Downloads$ perf report --sort comm,dso
+   58.47% 0.00%wireshark  [unknown]
+   34.86%15.55%wireshark  libQt5Gui.so.5.3.2
+   21.56%20.78%wireshark  libQt5Widgets.so.5.3.2
+   11.88% 8.99%wireshark  libc-2.19.so
+9.50% 9.42%wireshark  libglib-2.0.so.0.4800.0
+8.90% 7.35%wireshark  libwireshark.so.8.1.2
+8.75% 8.75%wireshark  [kernel.kallsyms]
+8.06% 7.51%wireshark  libQt5Core.so.5.3.2
+7.12% 3.97%wireshark  ld-2.19.so
+5.45% 5.45%wireshark  libfontconfig.so.1.8.0
+5.33% 5.33%wireshark  libz.so.1.2.8
+1.75% 1.75%wireshark  libpng12.so.0.50.0
+1.29% 1.29%  QThread  [kernel.kallsyms]
+1.15% 1.13%wireshark  i965_dri.so
+0.82% 0.13%wireshark  wireshark
+0.50% 0.50%wireshark  libfreetype.so.6.11.1
+0.46% 0.15%wireshark  libX11.so.6.3.0
+0.40% 0.40%wireshark  libharfbuzz.so.0.935.0
+0.30% 0.30%wireshark  libexpat.so.1.6.0
+0.28% 0.00%wireshark  libnl-genl-3.so.200.19.0
+0.28% 0.16%wireshark  libqxcb.so
+0.20% 0.20%wireshark  libnettle.so.4.7
+0.16% 0.00%  QXcbEventReader  [unknown]
+0.16% 0.16%  QXcbEventReader  [kernel.kallsyms]
+0.16% 0.03%  QXcbEventReader  libpthread-2.19.so
+0.16% 0.16%wireshark  liblua5.2.so.0.0.0
+0.15% 0.00%wireshark  libdl-2.19.so
+0.15% 0.08%wireshark  libpthread-2.19.so

I don't see anything related to that.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Segfault when running older Wireshark with capture from CVE-2013-4075

[Bálint Réczey]

2016-11-11 11:43 GMT+01:00 Guy Harris :
> On Nov 11, 2016, at 1:59 AM, Anders Broman  wrote:
>
>> https://wiki.wireshark.org/Development/LifeCycle
>>
>> Version  Stable Release Date  End of LifeNotes
>>
>> 1.8  June 21, 2012 June 21, 2014 Last release to support 
>> OS X on PPC
>>
>> 1.8 vent end-of-life June 21, 2014
>
> So the advice we have to offer is that you should either
>
> 1) update to a newer version of Wireshark that doesn't have the bug
>
> or
>
> 2) get the 1.8.x source, apply the fix yourself, recompile, and use 
> that version

I maintain lts-* [1] branches mainly for organizing security patches
for Debian, but the
1.8 one is not active anymore. You may find fixes in those branches
which may be useful
for you in other cases.

Security releated patches are also welcome for the active branches which is only
lts-1.121 at the moment.

Cheers,
Balint

[1] https://code.wireshark.org/review/gitweb?p=wireshark.git;a=summary
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] unable to compile wireshark-2.0.1 on Ubuntu 14.04

[Bálint Réczey]

Hi,

2016-11-08 22:43 GMT+01:00 Vidya Dharmaraju :
> Hi wireshark-dev,
>
>
>
> I am unable to compile wireshark 2 on Ubuntu 14.04
>
>
>
> Need some quick help here – any clues, please share.
>
>
>
> Attached is the 1) config.log 2) Compile errors with make
>
>
>
> Steps followed:
>
> 1)
>
> sudo apt-get build-dep wireshark
>
> sudo apt-get install qtbase5-dev qtbase5-dev-tools qttools5-dev
> qttools5-dev-tools qtmultimedia5-dev libqt5svg5-dev
>
>
>
> 2)
>
> ./configure
>
>
>
> Loaded whatever packages ./configure said are missing.
>
>
>
> 3)
>
> make
>
>
>
> Following is the error I get, I do have libtool installed already:
>
>
>
>
>
> root@vidya-Latitude-E6410:~/wireshark/Wireshark-dev-master/wireshark-2.0.1#

Compiling as root is usally a bad idea.

The build dependencies include the packages to compile Wireshark with
cmake, not with autotools.

Please run:
 cmake . && make
in wireshark's build directory.

Reading README.cmake would also be a idea.

Cheers,
Balint


> make
>
>   PERL version.h
>
> Version configuration file version.conf not found.  Using defaults.
>
> version.h unchanged.
>
> make  all-recursive
>
> make[1]: Entering directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
> Making all in tools
>
> make[2]: Entering directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1/tools'
>
> make[3]: Entering directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
> make[3]: Leaving directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
> Making all in lemon
>
> make[3]: Entering directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1/tools/lemon'
>
> make[4]: Entering directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
> make[4]: Leaving directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
> make[3]: Nothing to be done for `all'.
>
> make[3]: Leaving directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1/tools/lemon'
>
> make[3]: Entering directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1/tools'
>
> make[4]: Entering directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
> make[4]: Leaving directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
> sed \
>
> -e 's,@BIN_PREFIX\@,/usr/local/bin,' \
>
> -e 's,@TSHARK_BIN\@,tshark,' \
>
> -e 's,@DUMPCAP_BIN\@,dumpcap,' \
>
> < ./setuid-root.pl.in > setuid-root.pl
>
> chmod +x setuid-root.pl
>
> make[3]: Leaving directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1/tools'
>
> make[2]: Leaving directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1/tools'
>
> Making all in wsutil
>
> make[2]: Entering directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1/wsutil'
>
> make[3]: Entering directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
> make[3]: Leaving directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
>   CC   adler32.lo
>
> /bin/bash: line 1: @LIBTOOL@: command not found
>
> make[2]: *** [adler32.lo] Error 127
>
> make[2]: Leaving directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1/wsutil'
>
> make[1]: *** [all-recursive] Error 1
>
> make[1]: Leaving directory
> `/home/vidya/wireshark/Wireshark-dev-master/wireshark-2.0.1'
>
> make: *** [all] Error 2
>
>
>
>
>
> root@vidya-Latitude-E6410:~/wireshark/Wireshark-dev-master/wireshark-2.0.1#
> which libtool
>
> /usr/bin/libtool
>
> root@vidya-Latitude-E6410:~/wireshark/Wireshark-dev-master/wireshark-2.0.1#
> find / -name libtool -print
>
> /usr/share/libtool
>
> /usr/share/doc/libtool
>
> /usr/bin/libtool
>
>
>
>
>
> Thank you!
>
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Bálint Réczey]

Hi,

2016-08-05 23:31 GMT+02:00 Guy Harris :
...
>
> 'debian/rules' has non-whitelisted license 'UNKNOWN'
> 'debian/copyright' has non-whitelisted license 'LGPL (v2 or later) 
> GPL (v2 or later) LGPL (v2 or later)'
> 'debian/compat' has non-whitelisted license 'UNKNOWN'
> 'debian/geoip_db_paths' has non-whitelisted license 'UNKNOWN'
> 'debian/dirs' has non-whitelisted license 'UNKNOWN'
> 'debian/control' has non-whitelisted license 'UNKNOWN'
> 'debian/changelog' has non-whitelisted license 'UNKNOWN'
> 'debian/patches/series' has non-whitelisted license 'UNKNOWN'
> 'debian/templates' has non-whitelisted license 'UNKNOWN'
> 'debian/postinst' has non-whitelisted license 'UNKNOWN'
> 'debian/license-text-about-dialog' has non-whitelisted license 
> 'UNKNOWN'
> 'debian/source/format' has non-whitelisted license 'UNKNOWN'
>
> Balint?  What does Debian do about licenses on these sorts of files?

Generally the recommended practice is using the machine readable
copyright in which all files are covered including the ones in debian/:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
...

Files: *
Copyright: 1975-2010 Ulla Upstream
License: GPL-2+

Files: debian/*
Copyright: 2010 Daniela Debianizer
License: GPL-2+

Files: debian/patches/fancy-feature
Copyright: 2010 Daniela Debianizer
License: GPL-3+

Files: */*.1
Copyright: 2010 Manuela Manpager
License: GPL-2+
...

It is also recommended to use the same license for the files in debian/
as used by upstream.
Files not including copyright information is considered to be licensed by
the project's main license, in our case GPL-2+, and in my opinion,
the files in debian/ are covered by GPL-2+, too.

Cheers,
Balint

PS: Rewriting the copyright file to the new format is something I should
have done long time ago. :-\
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Happy-shark or per-PDU regression tests

[Bálint Réczey]

Hi,

With Dario and Peter we created a small regression test suit aiming at
checking the dissection engine with very targeted tests.

It compares specific PDU's PDML representation against stored references.

You can find it on GitHub:
https://github.com/wireshark/happy-shark

Feel free to add your favorite protocols, pull requests are welcome!

Cheers,
Balint

PS: Eventually the repository may be migrated to Gerrit.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Debian builds in wireshark

[Bálint Réczey]

2016-04-29 11:12 GMT+02:00 Bálint Réczey <bal...@balintreczey.hu>:
> Hi Born,
>
> 2016-04-25 21:30 GMT+02:00 Born In <d3c1...@yahoo.com>:
>> Thanks Balint,
>>  Do you know if dpkg-buildpackage also builds the asn.1 structures inside
>> epan/dissectors/asn1// (which is usually built by going into
>> the specific folder and issuing a make)?
>
> dpkg-buildpackage calls cmake then make, thus it does not regenerate the
> code for the ASN.1 based dissectors. I have prepared a patch to change that
> which I will submit when gerrit accepts new changes again.

And right after I sent this email Gerrit accepted my changeset :-):
https://code.wireshark.org/review/#/c/15161/1

>
> Cheers,
> Balint
>
>>
>> Regards.
>>
>>
>>
>> On Monday, April 25, 2016 2:06 PM, Bálint Réczey <bal...@balintreczey.hu>
>> wrote:
>>
>>
>> Hi Born,
>>
>> 2016-04-25 19:46 GMT+02:00 Born In <d3c1...@yahoo.com>:
>>> When I try to build an installer package for Ubuntu (Debian), I am asked
>>> (per the INSTALL doc in the root folder) to execute: "dpkg-buildpackage
>>> -us
>>> -uc -rfakeroot" before I use configure/make etc.
>>> However, after I checkout the source, make the required changes to the
>>> code
>>> and run the command, it creates a folder called debian with a bunch of
>>> files
>>> and directories, but no .deb files.
>>> Is there a place that explains this process in detail? (For ex. if I'm
>>> changing something inside a folder in epan/dissectors/asn1/, will the dpkg
>>> command internally build the changed code or do I need to compile it first
>>> and then run the dpkg command?
>>
>> The .debs will be at ../ .
>>
>> Cheers,
>> Balint
>>
>>
>>
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Debian builds in wireshark

[Bálint Réczey]

Hi Born,

2016-04-25 21:30 GMT+02:00 Born In <d3c1...@yahoo.com>:
> Thanks Balint,
>  Do you know if dpkg-buildpackage also builds the asn.1 structures inside
> epan/dissectors/asn1// (which is usually built by going into
> the specific folder and issuing a make)?

dpkg-buildpackage calls cmake then make, thus it does not regenerate the
code for the ASN.1 based dissectors. I have prepared a patch to change that
which I will submit when gerrit accepts new changes again.

Cheers,
Balint

>
> Regards.
>
>
>
> On Monday, April 25, 2016 2:06 PM, Bálint Réczey <bal...@balintreczey.hu>
> wrote:
>
>
> Hi Born,
>
> 2016-04-25 19:46 GMT+02:00 Born In <d3c1...@yahoo.com>:
>> When I try to build an installer package for Ubuntu (Debian), I am asked
>> (per the INSTALL doc in the root folder) to execute: "dpkg-buildpackage
>> -us
>> -uc -rfakeroot" before I use configure/make etc.
>> However, after I checkout the source, make the required changes to the
>> code
>> and run the command, it creates a folder called debian with a bunch of
>> files
>> and directories, but no .deb files.
>> Is there a place that explains this process in detail? (For ex. if I'm
>> changing something inside a folder in epan/dissectors/asn1/, will the dpkg
>> command internally build the changed code or do I need to compile it first
>> and then run the dpkg command?
>
> The .debs will be at ../ .
>
> Cheers,
> Balint
>
>
>
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Debian builds in wireshark

[Bálint Réczey]

Hi Born,

2016-04-25 19:46 GMT+02:00 Born In :
> When I try to build an installer package for Ubuntu (Debian), I am asked
> (per the INSTALL doc in the root folder) to execute: "dpkg-buildpackage -us
> -uc -rfakeroot" before I use configure/make etc.
> However, after I checkout the source, make the required changes to the code
> and run the command, it creates a folder called debian with a bunch of files
> and directories, but no .deb files.
> Is there a place that explains this process in detail? (For ex. if I'm
> changing something inside a folder in epan/dissectors/asn1/, will the dpkg
> command internally build the changed code or do I need to compile it first
> and then run the dpkg command?
The .debs will be at ../ .

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark 2.01 packages in Ubuntu ppa

[Bálint Réczey]

Hi Peter,

2016-01-13 1:11 GMT+01:00 Peter Wu <pe...@lekensteyn.nl>:
> On Sun, Jan 10, 2016 at 11:52:39AM +0100, Bálint Réczey wrote:
>> Hi,
>>
>> 2016-01-09 16:40 GMT+01:00 Peter Wu <pe...@lekensteyn.nl>:
>> > Hi Bernard,
>> >
>> > On Thu, Jan 07, 2016 at 12:31:12PM -0500, bernard ck Wong wrote:
>> >> I have installed wireshark2.01 from the wireshark stable ppa on Wily (64
>> >> bit) and wireshark-gtk crashes immediately. The errors are in attachment.
>> >> The  package for vivid 64 bit works without issue though.
>> >>
>> >> I just compiled 2.01 from source and it didn't crash.
>> >
>> > Can you please post the outptu of:
>> >
>> > tshark -G currentprefs | grep gui.layout_type
>> >
>> > If it is "#gui.layout_type: 1" (or something in the range 1-6) and still
>> > crashes, then maybe some memory is scribbled. Can you try to reproduce
>> > the issue with a clean configuration? Example:
>> >
>> > HOME=/tmp/wshome wireshark
>> I have reproduced the issue in a clean Wily VM.
>> And did short triaging:
>>
>> #4  0x5653770ef3e3 in main_widgets_rearrange () at
>> /home/vagrant/wireshark-2.0.1+g59ea380/ui/gtk/main.c:3491
>> 3491g_assert_not_reached();
>> (gdb) p prefs.gui_layout_type
>> $1 = layout_unused
>>
>> Recompilation does not help and the preferences file is not created.
>>
>> The Qt version and tshark start fine.
>
> Can you try this fix (for master, but should be backported too):
> https://code.wireshark.org/review/13154
>
> It also means that somehow the gui.layout_type field was set to 0... But
> the default on master-2.0 is:
>
> epan/prefs.c:3032:prefs.gui_layout_type = layout_type_5;
>
> Does Ubuntu include a default prefs file having gui.layout_type:0?
Sorry for not posting here earlier, but the crash is fixed or at least
shadowed by this commit:
https://code.wireshark.org/review/#/c/13178/

You may want to revert it before testing other possible fixes.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark 2.01 packages in Ubuntu ppa

[Bálint Réczey]

Hi,

2016-01-09 16:40 GMT+01:00 Peter Wu :
> Hi Bernard,
>
> On Thu, Jan 07, 2016 at 12:31:12PM -0500, bernard ck Wong wrote:
>> I have installed wireshark2.01 from the wireshark stable ppa on Wily (64
>> bit) and wireshark-gtk crashes immediately. The errors are in attachment.
>> The  package for vivid 64 bit works without issue though.
>>
>> I just compiled 2.01 from source and it didn't crash.
>
> Can you please post the outptu of:
>
> tshark -G currentprefs | grep gui.layout_type
>
> If it is "#gui.layout_type: 1" (or something in the range 1-6) and still
> crashes, then maybe some memory is scribbled. Can you try to reproduce
> the issue with a clean configuration? Example:
>
> HOME=/tmp/wshome wireshark
I have reproduced the issue in a clean Wily VM.
And did short triaging:

#4  0x5653770ef3e3 in main_widgets_rearrange () at
/home/vagrant/wireshark-2.0.1+g59ea380/ui/gtk/main.c:3491
3491g_assert_not_reached();
(gdb) p prefs.gui_layout_type
$1 = layout_unused

Recompilation does not help and the preferences file is not created.

The Qt version and tshark start fine.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] UI Proposal for better Analysis for Android devices

[Bálint Réczey]

2015-12-31 0:10 GMT+01:00 Anders Broman :
>
> Den 30 dec 2015 17:01 skrev "Graham Bloice" :
>>
>>
>>
>> On 30 December 2015 at 10:52, VIKRAM VENKATESH HEGDE
>>  wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> Sure, will submit the feature in patches may be will start doing so by
>>> next week.
>>>
>>> Thanks for the support.
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Vikram
>>>
>>>
>>
>> FWIW, I have a different opinion than Anders regarding the UI.   Qt "is"
>> the Wireshark UI toolkit, GTK is legacy, and Qt is better supported on our
>> target platforms, especially OSX.  I think any new UI development should be
>> for Qt first, then if developer cycles are available, it can be ported to
>> GTK.
>
> As I understand it in this case the GTK code exist and the Qt does not. Not
> accepting it would slow progress and accepting it might speed up the port to
> Qt and sort out any problems or design flaws early. IMHO
I agree that we should not reject UI patches because they improve the GTK+
implementation only.

I would prefer having Wireshark development guided by users' needs and
contributions
rather than pushing devs' choices very hard [1].

Cheers,
Balint

[1] In Debian we have the social contract clarifying that:
...
4. Our priorities are our users and free software
We will be guided by the needs of our users and the free software
community. We will place their interests first in our priorities. We
will support the needs of our users for operation in many different
kinds of computing environments. ...
...
(From: https://www.debian.org/social_contract)

> Regards
> Anders
>
>>
>>> --- Original Message ---
>>>
>>> Sender : Anders Broman
>>>
>>> Date : Dec 30, 2015 16:59 (GMT+09:00)
>>>
>>> Title : RE: [Wireshark-dev] UI Proposal for better Analysis for Android
>>> devices
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: wireshark-dev-boun...@wireshark.org
>>> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of VIKRAM VENKATESH
>>> HEGDE
>>> Sent: den 29 december 2015 06:57
>>> To: wireshark-dev@wireshark.org
>>> Subject: [Wireshark-dev] UI Proposal for better Analysis for Android
>>> devices
>>>
>>>
>>>
>>> Dear All,
>>>
>>>
>>>
>>> Its my pleasure to contribute to Wireshark Open Source community. Off
>>> late our team is contributing to Zigbee cluster dissectors.
>>>
>>> We have a UI feature proposal to contribute to open source which will
>>> result in improved and better analysis of issues with respect to android
>>> devices also providing user with a good use experience. Below are the
>>> details of the proposed solution, also attached are the screenshots of the
>>> idea in which one reflects the existing flow graph available in Wireshark,
>>> and the other screenshot represents the change we are proposing to enhance
>>> the UI and separate packet  and system logs and show the system logs in
>>> separate panel:
>>>
>>>
>>>
>>> Title
>>>
>>> UI Feature in Wireshark for better analysis
>>>
>>> Abstract
>>>
>>> The proposed solution addresses enhancement of UI for GTK, in which
>>> unlike the existing Wireshark, the logs which are generated from the android
>>> device connected via usb to system and the packet data are separated out to
>>> show it in different panes. Thus providing an additional functionality of
>>> viewing the log data and packet data separately and also having a time
>>> synchronization functionality to map the packet data with the log entry and
>>> vice-versa. This will be useful for user to analyze the particular scenario
>>> in more depth as the user will be able to analyze whether the issue lies in
>>> network based on the packets or whether the issue lies in the device
>>> software implementation based on the system logs.
>>>
>>> Background (if necessary)
>>>
>>> The code contribution is an enhancement of existing Wireshark to provide
>>> user with more functionality and better analysis of the issues. Also
>>> enhancing the user experience by showing the log data and packet data
>>> together and mapping functionality based on the time.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Detailed Description
>>>
>>> Added the below functionalities:
>>>
>>> v  Modified the UI to show device system logs and packet logs separately.
>>>
>>> v  Time Synchronization and mapping between packet data and system logs
>>> so that user can get the issues addressed more clearly.
>>>
>>> The system logs that are captured using the existing android dump are
>>> shown in the form of packets along with the other network traffic in the
>>> Wireshark main packet window.  This implementation adds large number of
>>> additional packets in the Wireshark packet window as every log line is shown
>>> as a packet. To reduce this overhead we are segregating the log viewer and
>>> the network traffic by adding additional UI component Logviewer. The log
>>> viewer will display the system logs as simple text data . The user can map
>>> between 

Re: [Wireshark-dev] -fPIC on Ubuntu Wily

[Bálint Réczey]

Hi All,

I sadly became more and more convinced that starting the adoption of
compiling with -fPIE was an overly optimistic move on my side. :-(
It seems that there are too many integration corner cases to handle
where -fPIE breaks and it may be a better idea to let the
distribution-specific scripts like debian/rules set it on systems
where it is known to work out of the box.

What do you think about that approach?

Cheers,
Balint

2015-10-31 0:11 GMT+04:00 Hauke Mehrtens :
> On 10/27/2015 11:45 PM, Evan Huus wrote:
>> After recently upgrading to Ubuntu 15.10, my cmake configure failed with:
>> -- Performing Test WORKS_WITH_FPIC - Failed
>> CMake Error at CMakeLists.txt:938 (message):
>>   Couldn't compile Qt without -fPIC nor with -fPIC
>>
>> Digging into the logs, the test being run (and its output) is as follows:
>>
>> /usr/bin/c++-Wall -W -Wextra -Wendif-labels -Wpointer-arith
>> -Warray-bounds -Wformat-security -fwrapv -fno-strict-overflow
>> -fno-delete-null-pointer-checks -Wvla -Waddress -Wattributes
>> -Wdiv-by-zero -Wignored-qualifiers -Wpragmas -Wno-overlength-strings
>> -Wwrite-strings -Wno-long-long -fexcess-precision=fast
>> -DWORKS_WITH_FPIC -fPIC -fPIE -I/usr/include/x86_64-linux-gnu/qt5
>> -I/usr/include/x86_64-linux-gnu/qt5/QtCore
>> -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64-o
>> CMakeFiles/cmTryCompileExec1538407922.dir/src.cxx.o -c
>> /home/eapache/pkg/linux_amd64/wireshark.org/wireshark/CMakeFiles/CMakeTmp/src.cxx
>> In file included from
>> /usr/include/x86_64-linux-gnu/qt5/QtCore/qnamespace.h:37:0,
>>  from 
>> /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs.h:41,
>>  from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:40,
>>  from
>> /usr/include/x86_64-linux-gnu/qt5/QtCore/qabstractanimation.h:37,
>>  from /usr/include/x86_64-linux-gnu/qt5/QtCore/QtCore:4,
>>  from
>> /home/eapache/pkg/linux_amd64/wireshark.org/wireshark/CMakeFiles/CMakeTmp/src.cxx:1:
>> /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1052:4: error:
>> #error "You must build your code with position independent code if Qt
>> was built with -reduce-relocations. " "Compile your code with -fPIC
>> (-fPIE is not enough)."
>>  #  error "You must build your code with position independent code if
>> Qt was built with -reduce-relocations. "\
>> ^
>>
>> I suspect because we are passing both -fPIC *and* -fPIE (and that
>> -fPIE is being passed second) something is not working correctly? I'm
>> not familiar with how those flags work together.
>>
>> Thoughts?
>> Evan
>
> Hi,
>
> I have the same problem in debian testing with QT 5.4 and also with the
> new qt5.5.1 which I got as a normal update today.
>
> Here is the issue:
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11643
>
> Here someone else reported the same problem some time ago:
> https://www.wireshark.org/lists/wireshark-bugs/201505/msg00563.html
>
> Hauke
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Moving codecs to libwireshark or libwsutil?

[Bálint Réczey]

2015-12-02 21:25 GMT+01:00 Pascal Quantin :
>
>
> 2015-11-30 20:15 GMT+01:00 Guy Harris :
>>
>>
>> On Nov 30, 2015, at 11:07 AM, Pascal Quantin 
>> wrote:
>>
>>
>> > Yes I should have been clearer in my initial description.
>> > My suggestion with an extra parameter giving the hash table address is
>> > also working fine, so I do not have a strong feeling either way (the 
>> > changed
>> > parameter is faster to do but might not be the best long term solution).
>>
>> Unless there's some compelling reason for them *not* to be in a dynamic
>> library, I think making libcodec a dynamic library the best long-term
>> solution.
>>
>> > If possible I would like to have this fixed for Wireshark 2.0.1 but I
>> > wonder if such change is compatible with our usual policy to keep APIs
>> > constant (does it apply when they are buggy?).
>>
>> Making it a dynamic library wouldn't change the API.
>
>
> Done: https://code.wireshark.org/review/#/c/12385/1
The discussion continued in the review, please join it if you feel so there.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] wiretap - using as a library rather than coupled with Wireshark?

[Bálint Réczey]

Hi Dario,

You did not write the platforms you want to support, but in case it is just
Ubuntu/Debian there are pre built wiretap headers and librerary for your
consumption :-):
https://packages.debian.org/unstable/libwiretap-dev

It releasing the new software under GPL2+ we can integrate it to wireshark az
a helper program an you may make like really easy for your users. :-)

Cheers,
Balint

2015-11-27 9:23 GMT+01:00 Dario Lombardo :
> The scenario I was figuring out was to have a software that wants to
> leverage the libwiretap features. The user could build wiretap in the
> original wireshark dir, as normal. Then it could compile/link the new
> software againts the compiled lib. That implies a process made by hand and
> not semi-automated. This couldn't apply to a released software, whose
> requiremets include wiretap, but could apply to scenarios of task-oriented
> softwares (I mean not general purpose ones).
>
> On Thu, Nov 26, 2015 at 7:54 PM, Guy Harris  wrote:
>>
>>
>> On Nov 26, 2015, at 1:18 AM, Dario Lombardo 
>> wrote:
>>
>> > Provided that this is not a published lib, that has an unstable
>> > interface, that... whatever constraint you can figure out, I think that it
>> > could be used "as-is". To achive that wouldn't be enough to add the 
>> > wiretap/
>> > to the include dirs of the compiler and the compiled .so to the linker? Is
>> > there a step I am missing?
>>
>> That depends on what Richard means by "independently of Wireshark".
>>
>> If he means "can I extract the source to libwiretap, and have a source
>> tree with *only* that, and not bother building the rest of Wireshark?", then
>> the steps you're missing are the steps to do exactly that (and to extract
>> the source to libwsutils).
>
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] wiretap - using as a library rather than coupled with Wireshark?

[Bálint Réczey]

2015-11-27 9:45 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
> Hi Dario,
>
> You did not write the platforms you want to support, but in case it is just
> Ubuntu/Debian there are pre built wiretap headers and librerary for your
> consumption :-):
> https://packages.debian.org/unstable/libwiretap-dev
>
> It releasing the new software under GPL2+ we can integrate it to wireshark az
> a helper program an you may make like really easy for your users. :-)
I haven't really woken up this morning :-) So:

If releasing the new software under GPL2+ is OK for you we can integrate it to
Wireshark as a helper program and you may make life really easy for
your users. :-)

>
> Cheers,
> Balint
>
> 2015-11-27 9:23 GMT+01:00 Dario Lombardo <dario.lombardo...@gmail.com>:
>> The scenario I was figuring out was to have a software that wants to
>> leverage the libwiretap features. The user could build wiretap in the
>> original wireshark dir, as normal. Then it could compile/link the new
>> software againts the compiled lib. That implies a process made by hand and
>> not semi-automated. This couldn't apply to a released software, whose
>> requiremets include wiretap, but could apply to scenarios of task-oriented
>> softwares (I mean not general purpose ones).
>>
>> On Thu, Nov 26, 2015 at 7:54 PM, Guy Harris <g...@alum.mit.edu> wrote:
>>>
>>>
>>> On Nov 26, 2015, at 1:18 AM, Dario Lombardo <dario.lombardo...@gmail.com>
>>> wrote:
>>>
>>> > Provided that this is not a published lib, that has an unstable
>>> > interface, that... whatever constraint you can figure out, I think that it
>>> > could be used "as-is". To achive that wouldn't be enough to add the 
>>> > wiretap/
>>> > to the include dirs of the compiler and the compiled .so to the linker? Is
>>> > there a step I am missing?
>>>
>>> That depends on what Richard means by "independently of Wireshark".
>>>
>>> If he means "can I extract the source to libwiretap, and have a source
>>> tree with *only* that, and not bother building the rest of Wireshark?", then
>>> the steps you're missing are the steps to do exactly that (and to extract
>>> the source to libwsutils).
>>
>>
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] CMake: Disable building with QT ?

[Bálint Réczey]

Hi,

To enable completion you also need the bash-completion package
installed and sourced in your bash session.
Sometimes the bash-completion package is missing in VM-s to save
space, but on default Ubuntu Desktop it is installed and enabled.

Bash-completion performs the completion part and uses the rules
shipped by cmake:

$ dpkg -S /etc/bash_completion.d/cmake
cmake: /etc/bash_completion.d/cmake

Cheers,
Balint

2015-11-14 21:16 GMT+04:00 Dario Lombardo :
> cmake completion on ubuntu leverage the cmake build dir itself. If you run
> cmake once, then try the completion, it will do the trick
>
> $ mkdir build
> $ cd build
> $ cmake ..
> [build dir is populated]
> $ cmake -D
>
> It works for me in a freshly created build dir.
>
> On Fri, Nov 13, 2015 at 11:34 PM, Guy Harris  wrote:
>>
>>
>> On Nov 13, 2015, at 12:26 AM, Dario Lombardo 
>> wrote:
>>
>> > A useful feature of cmake that works at least on ubuntu is the tab
>> > completion. So you can run
>> >
>> > cmake -DBUILD
>> >
>> > and you get a list of build targets that can be enabled/disabled.
>>
>> Not on my Ubuntu 15.10 virtual machine it doesn't - not even if I run it
>> in the Wireshark source directory.   does nothing.
>>
>> $ cmake --version
>> cmake version 3.2.2
>> $ echo $SHELL
>> /bin/bash
>> $ bash --version
>> GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu)
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>>
>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
>
>
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] GCC GTK3 Wireshark build warnings ?

[Bálint Réczey]

2015-11-11 22:10 GMT+04:00 Jeff Morriss :
> On 11/11/15 12:28, Bill Meier wrote:
>>
>> When building GTK3 Wireshark on my Fedora system (after not having done
>> so for a while), I'm getting many warnings similar to the following:
>>
>>
>>   CC   libgtkui_a-about_dlg.o
>> In file included from /usr/include/gtk-3.0/gtk/gtk.h:263:0,
>>   from about_dlg.c:28:
>> /usr/include/gtk-3.0/gtk/deprecated/gtkstyle.h:454:43: error: identifier
>> "and" is a special operator name in C++ [-Werror=c++-compat]
>>   GDK_DEPRECATED_IN_3_0_FOR(GtkStyleContext and gtk_render_background)
>> ^
>>
>> [versions: Fedora 23; GCC 5.1.1; GTK3 3.18.2]
>>
>> -Wc++-compat seems to have been added in March 2013 (g557df88), so I
>> don't know why I'm now getting the warnings (although it's been some
>> number of months since I've built GTK3 Wireshark with GCC);
>>   Warnings didn't show with previous versions of GCC compiler ?
>>   GTK changes ??
>>   ???
>
>
> It looks like Balint already sent a patch to Gtk:
>
> https://www.wireshark.org/lists/wireshark-dev/201403/msg00042.html
It seems to be a new breakage, I have to check it.

>
>> So: it seems we want to continue to support GTK3 ?
>
>
> Yes, I think so.  At least RHEL 6 needs to continue to use the Gtk+ GUI
> (since its Qt isn't new enough).  (Though I still stick with Gtk2.)
>
>> and thus it seems that the -Wc++-compat compile flag would need to be
>> removed when building GTK stuff or ??
>
>
> That's probably not unreasonable (as long as the rest of Wireshark still
> gets the flag).
As a workaround one can pass -Wno-c++-compat as an extra flag to build
local Wireshark versions without having to patch anything.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Master-2.0 reminder and Buildbot updates

[Bálint Réczey]

Hi Gerald,

2015-10-02 22:51 GMT+02:00 Gerald Combs :
> As a quick reminder, the master-2.0 branch and builders will be created on
> Monday. I've also made the following changes in our Buildbot environment:
>
> - Upgraded to Qt 5.3.2 on the Windows 64-bit, 32-bit, and Petri dish builders.
>
> - Installed Qt 5.5.0 on the Windows 64-bit, 32-bit, and PD builders. We're
> still building with 5.3.2 for now but can switch to 5.5.0 if needed.
>
> - Switched to shallow Git checkouts on the Windows PD builder.
>
> - Switched OS X 64-bit and 32-bit .dmg packaging from Autotools to CMake.
Should I switch to Qt 5 in the .deb generation scripts, too? Wireshark
already use Qt 5 in Debian stable/testing/unstable.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Wireshark and hardening flags

[Bálint Réczey]

Hi All,

I have just created a review to add PIE when it is available to default flags:
https://code.wireshark.org/review/#/c/10635

I think this matter is worth discussion here, too.
Should we enable more compiler flags which make Wireshark more secure
by default?

I Debian I will enable all hardening flags thus Debian users will be
protected, but I wonder if we want to enable some of them in vanilla
Wireshark as well.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Planning the next major release

[Bálint Réczey]

2015-06-06 11:23 GMT+02:00 Alexis La Goutte alexis.lagou...@gmail.com:
 Hi,

 On Fri, Jun 5, 2015 at 3:39 PM, Bálint Réczey bal...@balintreczey.hu
 wrote:

 Hi,

 2015-06-04 23:58 GMT+02:00 Gerald Combs ger...@wireshark.org:
  We often make major releases in June, just before Sharkfest. That
  probably
  won't happen this year. A major release now would mean either releasing
  2.0
  (featuring the Qt UI) without feature parity with the GTK+ UI, or
  releasing
  1.14 (featuring the GTK+ UI). I'm not particularly fond of either
  choice.
 
  Unless there's a compelling reason to get something out the door now,
  I'd
  prefer to wait until the Qt UI is ready, which raises the question of
  the
  definition of ready. We've been tracking complete and pending features
  at
 
  https://wiki.wireshark.org/Development/QtShark
 
  We've made a lot of progress but are still lacking many features
  including
  the Wireless Toolbar, a few Statistics dialogs, and quite a few
  Telephony
  dialogs.
 IMO it would be a great disservice to our users to release Wireshark
 with the current Qt state causing regressions due to missing features.
 I also think that delaying our established release cycle time-wise
 indefinitely would also be a disservice since Wireshark is a
 professional tool and our users are expecting use to provide a new
 release around June and they may have committed upgrade plans.
 Implementing the remaining missing functionality in a rush and
 releasing with Qt as a default UI is also something which I would not
 do, because the newly implemented parts would not be tested
 extensively.

 The GTK+ UI is in a releasable state AFAIK thus I propose releasing
 1.14 with GTK+ shortly after Sharkfest because it is the best we can
 do four our users and we can fiinish the final touches during
 Sharkfest.
 The GTK+ UI can be made really nice on OS X using Homebrew [1] and I
 think nothing prevents us from providing a native Quartz UI on OS in
 our .dmg-s. I can work on this during Sharkfest.
 If someone beats me to that I plan fixing the Windows GTK+ builds and
 making them beautiful, too by switching to GTK+ 3.1x for 1.14. Doing
 the work on the OS X part took me about a week and I expect the
 Windows work to be about the same.


 The question is when Wireshark Qt will be feature parity with Wireshark GTK.
 If it is for 3 or 4 month (like September/October), it is possible to wait
 to release a new major release.
I would not delay the release that long and please consider the risks
of releasing code which is tested for only a short time.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Planning the next major release

[Bálint Réczey]

Hi,

2015-06-04 23:58 GMT+02:00 Gerald Combs ger...@wireshark.org:
 We often make major releases in June, just before Sharkfest. That probably
 won't happen this year. A major release now would mean either releasing 2.0
 (featuring the Qt UI) without feature parity with the GTK+ UI, or releasing
 1.14 (featuring the GTK+ UI). I'm not particularly fond of either choice.

 Unless there's a compelling reason to get something out the door now, I'd
 prefer to wait until the Qt UI is ready, which raises the question of the
 definition of ready. We've been tracking complete and pending features at

 https://wiki.wireshark.org/Development/QtShark

 We've made a lot of progress but are still lacking many features including
 the Wireless Toolbar, a few Statistics dialogs, and quite a few Telephony
 dialogs.
IMO it would be a great disservice to our users to release Wireshark
with the current Qt state causing regressions due to missing features.
I also think that delaying our established release cycle time-wise
indefinitely would also be a disservice since Wireshark is a
professional tool and our users are expecting use to provide a new
release around June and they may have committed upgrade plans.
Implementing the remaining missing functionality in a rush and
releasing with Qt as a default UI is also something which I would not
do, because the newly implemented parts would not be tested
extensively.

The GTK+ UI is in a releasable state AFAIK thus I propose releasing
1.14 with GTK+ shortly after Sharkfest because it is the best we can
do four our users and we can fiinish the final touches during
Sharkfest.
The GTK+ UI can be made really nice on OS X using Homebrew [1] and I
think nothing prevents us from providing a native Quartz UI on OS in
our .dmg-s. I can work on this during Sharkfest.
If someone beats me to that I plan fixing the Windows GTK+ builds and
making them beautiful, too by switching to GTK+ 3.1x for 1.14. Doing
the work on the OS X part took me about a week and I expect the
Windows work to be about the same.

Cheers,
Balint

[1] 
http://balintreczey.hu/blog/beautiful-wireshark-on-os-x-using-homebrew-and-gtk3quartz/
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Error: implicit declaration of function ‘gdk_pixbuf_new_from_inline’

[Bálint Réczey]

2015-05-20 13:43 GMT+02:00 Pascal Quantin pascal.quan...@gmail.com:
 2015-05-20 13:34 GMT+02:00 Andrei Emeltchenko
 andrei.emeltchenko.n...@gmail.com:

 Hi,

 recently I hit following error when building wireshark on Ubuntu 15.04:

 ...
   AR   libqtui.a
 make[2]: Leaving directory '/usr/local/wireshark/ui/qt'
 Making all in ui/gtk
 make[2]: Entering directory '/usr/local/wireshark/ui/gtk'
   CC   libgtkui_a-gui_utils.o
 gui_utils.c: In function ‘window_icon_realize_cb’:
 gui_utils.c:115:5: error: implicit declaration of function
 ‘gdk_pixbuf_new_from_inline’ [-Werror=implicit-function-declaration]
  icon = gdk_pixbuf_new_from_inline(-1, wsicon_16_pb_data, FALSE,
 NULL);
  ^
 gui_utils.c:115:10: error: assignment makes pointer from integer without
 a cast [-Werror]
  icon = gdk_pixbuf_new_from_inline(-1, wsicon_16_pb_data, FALSE,
 NULL);
   ^
 gui_utils.c:117:10: error: assignment makes pointer from integer without
 a cast [-Werror]
  icon = gdk_pixbuf_new_from_inline(-1, wsicon_32_pb_data, FALSE,
 NULL);
   ^
 gui_utils.c:119:10: error: assignment makes pointer from integer without
 a cast [-Werror]
  icon = gdk_pixbuf_new_from_inline(-1, wsicon_48_pb_data, FALSE,
 NULL);
   ^
 gui_utils.c:121:10: error: assignment makes pointer from integer without
 a cast [-Werror]
  icon = gdk_pixbuf_new_from_inline(-1, wsicon_64_pb_data, FALSE,
 NULL);
   ^
 gui_utils.c: In function ‘pixbuf_to_widget’:
 gui_utils.c:524:12: error: assignment makes pointer from integer without
 a cast [-Werror]
  pixbuf = gdk_pixbuf_new_from_inline(-1, pb_data, FALSE, NULL);
 ^
 cc1: all warnings being treated as errors
 Makefile:1816: recipe for target 'libgtkui_a-gui_utils.o' failed
 make[2]: *** [libgtkui_a-gui_utils.o] Error 1
 make[2]: Leaving directory '/usr/local/wireshark/ui/gtk'
 Makefile:3645: recipe for target 'all-recursive' failed
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory '/usr/local/wireshark'
 Makefile:2276: recipe for target 'all' failed
 make: *** [all] Error 2
 ...

 Anybody seen this?


 Hi Andrei,

 this is https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10750

 Balint, would you be OK to temporarily allow deprecated APIs until you have
 the time to work on it?
Sure, I already agreed to doing that in the bug.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master e16500e: Fix check for NUL at the end of a string.

[Bálint Réczey]

2015-05-13 0:26 GMT+02:00 Guy Harris g...@alum.mit.edu:

 On May 12, 2015, at 3:13 PM, Evan Huus eapa...@gmail.com wrote:

 Argh, one of these days I will learn to just put parentheses in rather
 than taking guesses at C operator precedence :(

 Yeah, the rule I've found works best for me is if you aren't certain, throw 
 parentheses at it.
Yes, in this case parentheses are a must.
I also llike putting them when the reader may not guess the precedence
correctly easily. This reader can be myself later ;-).

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] build fails with switch --without-qt

[Bálint Réczey]

Could you please try:
git clean -dxf  dpkg-buildpackage -us -uc -rfakeroot
in the git directory?
The deb packages are known to build fine:
https://buildd.debian.org/status/package.php?p=wiresharksuite=unstable

Cheers,
Balint

2015-05-06 16:32 GMT+02:00 wulfman wulf...@wulfman.com:
 same error after

 git fetch wireshark
 ./autogen.sh
 ./configure --without-qt

 checking whether to use /usr/local for headers and libraries... yes
 checking for sed... (cached) /bin/sed
 checking for GNU sed as first sed in PATH... yes
 checking if profile builds must be generated... no
 configure: error: Neither Qt nor GTK+ 2.12.0 or later are available, so
 Wireshark can't be compiled


 I have both versions of gtk installed if that helps

 http://pastebin.com/R340sZkC

 On 5/5/2015 10:47 PM, Guy Harris wrote:
 On May 5, 2015, at 5:24 PM, evilwulfie evilwul...@gmail.com wrote:

 it seems that the --without-qt option breaks the check for GTK
 See the responses to the same messages from your other account.

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:https://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



 --
 The contents of this e-mail and any attachments are intended solely for the 
 use of the named
 addressee(s) and may contain confidential and/or privileged information. Any 
 unauthorized use,
 copying, disclosure, or distribution of the contents of this e-mail is 
 strictly prohibited by
 the sender and may be unlawful. If you are not the intended recipient, please 
 notify the sender
 immediately and delete this e-mail.

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:https://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] build fails with switch --without-qt

[Bálint Réczey]

2015-05-06 20:03 GMT+02:00 wulfman wulf...@wulfman.com:
 the command below gives this

 make[4]: *** [ui/qt/CMakeFiles/qtui.dir/color_utils.cpp.o] Error 1
 make[4]: Leaving directory `/root/wireshark/obj-arm-linux-gnueabihf'
 make[3]: *** [ui/qt/CMakeFiles/qtui.dir/all] Error 2
 make[3]: Leaving directory `/root/wireshark/obj-arm-linux-gnueabihf'
 make[2]: *** [all] Error 2
 make[2]: Leaving directory `/root/wireshark/obj-arm-linux-gnueabihf'
 dh_auto_build: make -j1 returned exit code 2
 make[1]: *** [override_dh_auto_build] Error 2
 make[1]: Leaving directory `/root/wireshark'
 make: *** [build] Error 2
 dpkg-buildpackage: error: debian/rules build gave error exit status 2

 which seems like its related to the same error i get when i compile with
 a ./ configure then a make
 related to qreal != double on armhf
It seems they == in Qt5. Are you building with Qt4?
From the cut log I can't tell.
See https://lists.debian.org/debian-arm/2013/11/msg00015.html .


 everything may be different if this is done using cross compiling on
 something other than arm board
I suspect something is special on your system. AFAIK buildds don't
cross compile for armhf.

Please set up an sbuild instance to build the package in a clean chroot:
https://wiki.debian.org/sbuild

Cheers,
Balint




 On 5/6/2015 7:45 AM, Bálint Réczey wrote:
 Could you please try:
 git clean -dxf  dpkg-buildpackage -us -uc -rfakeroot
 in the git directory?
 The deb packages are known to build fine:
 https://buildd.debian.org/status/package.php?p=wiresharksuite=unstable

 Cheers,
 Balint

 2015-05-06 16:32 GMT+02:00 wulfman wulf...@wulfman.com:
 same error after

 git fetch wireshark
 ./autogen.sh
 ./configure --without-qt

 checking whether to use /usr/local for headers and libraries... yes
 checking for sed... (cached) /bin/sed
 checking for GNU sed as first sed in PATH... yes
 checking if profile builds must be generated... no
 configure: error: Neither Qt nor GTK+ 2.12.0 or later are available, so
 Wireshark can't be compiled


 I have both versions of gtk installed if that helps

 http://pastebin.com/R340sZkC

 On 5/5/2015 10:47 PM, Guy Harris wrote:
 On May 5, 2015, at 5:24 PM, evilwulfie evilwul...@gmail.com wrote:

 it seems that the --without-qt option breaks the check for GTK
 See the responses to the same messages from your other account.

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:https://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


 --
 The contents of this e-mail and any attachments are intended solely for the 
 use of the named
 addressee(s) and may contain confidential and/or privileged information. 
 Any unauthorized use,
 copying, disclosure, or distribution of the contents of this e-mail is 
 strictly prohibited by
 the sender and may be unlawful. If you are not the intended recipient, 
 please notify the sender
 immediately and delete this e-mail.

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:https://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:https://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



 --
 The contents of this e-mail and any attachments are intended solely for the 
 use of the named
 addressee(s) and may contain confidential and/or privileged information. Any 
 unauthorized use,
 copying, disclosure, or distribution of the contents of this e-mail is 
 strictly prohibited by
 the sender and may be unlawful. If you are not the intended recipient, please 
 notify the sender
 immediately and delete this e-mail.

___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Windows automated builds migrated to CMake

[Bálint Réczey]

Great! Good job!

Cheers,
Balint

2015-04-16 10:19 GMT+02:00 Graham Bloice graham.blo...@trihedral.com:
 Woohoo.

 Change to delete *.nmake incoming :-)

 On 16 April 2015 at 04:06, Gerald Combs ger...@wireshark.org wrote:

 We reached a bit of a milestone today. The packages created by the
 32-bit and 64-bit Windows builders at
 https://buildbot.wireshark.org/trunk/waterfall are now produced using
 CMake and MSBuild.

 Thanks to everyone for helping to get the Windows CMake environment up
 and running!

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:https://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




 --
 Graham Bloice
 Software Developer
 Trihedral UK Limited

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:https://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Supported Python versions?

[Bálint Réczey]

Hi Peter,

2015-03-24 18:17 GMT+01:00 Peter Wu pe...@lekensteyn.nl:
 On Sun, Mar 22, 2015 at 04:58:14PM +0100, Pascal Quantin wrote:
 2015-03-22 16:48 GMT+01:00 Peter Wu pe...@lekensteyn.nl:

  Hi,
 
  Triggered by a build error due to html2text.py, I have recently started
  with adding Python 3 support to various Python scripts[1][2]. The change
  to html2text.py[1] was tested with Python 2.6, 2.7, 3.2 and 3.4.
 
  The configure script however checks for Python = 2.5 which was first
  released in 2006 with the last security update in 2011. This version
  also lacks support for nice language constructs such as 'with'.
  checklicenses.py is already incompatible with this.
 
  Any objections if this gets bumped to 2.6 or even 2.7? The
  dfilter-test.py script already requires 2.7 (or newer).
 

 Hi Peter,

 the OSX 10.5 x86 buildbot still runs Python 2.5, so bumping the minimum
 Python  version would require updating the buildbot. So it's better to keep
 compatibility for the scripts used during build steps.

 Pascal.

 According to the ComputerWorld source listed by Wikipedia[1], OS X 10.5
 became unsupported since June 2011. Python 2.5 also does not receive
 security updates anymore. (OS X 10.6 has Python 2.7 which is still
 supported.)
Since we use Python with verified input and only for building
Wireshark the security concerns don't apply here.
Otherwise I think it would be OK to move to newer Python version.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] dpkg-buildpackage -rfakeroot picking wrong version and dissectors

[Bálint Réczey]

Hi Juanjo,

2015-03-25 15:26 GMT+01:00 Juan Jose Martin Carrascosa jua...@rti.com:
 Hi all,

 I am building a package for Ubuntu, and the debian packages I get as result
 are not picking the proper customized version (set in configure.ac), but
 what is worse, a custom dissector I wrote is not in the packages.
The Debian packages use the cmake-based build system thus you have your
custimizations present there to be part of the packages.

Cheers,
Balint


 I did make before doing the packaging and ./wireshark-gtk is as I expect.

 Do I have to configure anything else before doing dpkg-buildpackage
 -rfakeroot?

 By the way, the rest of the build system works sweet in Centos, Mac and
 Windows.

 Thanks,
 Juanjo

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:https://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Use Transifex for manage Translations

[Bálint Réczey]

2015-03-03 11:58 GMT+01:00 Alexis La Goutte alexis.lagou...@gmail.com:


 On Tue, Feb 24, 2015 at 10:54 AM, Alexis La Goutte
 alexis.lagou...@gmail.com wrote:

 Hi,

 I have start to use Transifex web service to manage and follow Wireshark
 Translations.

 Transifex, it is a Gerrit of translation ;-), it is possible to review
 translation, add comment...

 The idea is manage directly translation with Transifex and refuse patch
 about translation on Gerrit.

 It is possible to download and reupload directy ts file (don't need
 Gerrit)

 I think, the translation will be resync (between Gerrit/Transifex) every
 week, i have start a script for launch this resync.


 Hi,


 It is ok for everybody ?
I don't plan working on translation thus it is OK with me if you would
like to manage translations there .

Do I understand correctly that you plan committing the translations in
bulk through Gerrit?
Either way please explain the change in the workflow on our wiki pages
about contributing patches.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Can we put android phone device connected over USB to Win 7 PC in promiscous mode?

[Bálint Réczey]

2015-02-24 12:12 GMT+01:00 Shashikant Ajegaonkar ajegaon...@gmail.com:
 Hi Balint and Michael,

 Thanks for the information.

 Hi Balint,

 Is there a way to save the captured files from wireshark running on Lil debi
 to the android device?
I have not tried that but I bet you can somehow see both filesystems.
If nothing else, scp would work.

Cheers,
Balint


 Is anyone aware of enumeration of WLAN interface from android phone  as WiFi
 interface (WLAN adapter) on Win 7 or Linux hosts?


 On Tue, Feb 24, 2015 at 2:54 PM, Bálint Réczey bal...@balintreczey.hu
 wrote:

 Hi Michal,

 2015-02-24 9:03 GMT+01:00 Michal Labedzki michal.labed...@tieto.com:
  Hello Bálint,
 
  That works as application on Android or OS? I am not sure that user
 Lil' Debi is an Android application that lets you install Debian on a
 loop device or in a chroot.
 Then you can run a shell or any command as an OS process.

  will be able to sniffing Android traffic on Debian like that.
 I did capture traffic originating from my (Nexus 7) tablet, thus it
 seems you can can capture everything.

 
  I see two cases:
  1. User want to capture Android traffic.
  2. User want to use Android device as... sniffer (monitor mode?) to
  capture air traffic.
 
  Lil' Debi - I cannot found it on Play Store. F-Droid too.
 It has been removed from Play Store, indeed.
 The F-Droid link seems to be OK and I also see it listed on on my
 Android devices in the F-Droid store.

 Cheers,
 Balint

 
  On 24 February 2015 at 08:42, Bálint Réczey bal...@balintreczey.hu
  wrote:
  2015-02-24 8:13 GMT+01:00 Shashikant Ajegaonkar ajegaon...@gmail.com:
  Hi All,
 
  Has anyone tried to put WiFi interface of Android device in promiscous
  mode?
  Is it possible to enumerate phone over adb interface as device
  wireless
  network interface in Win7 machine and configure it in promiscous mode
  for
  sniffer application?
  It is not Win 7 related, but you can run Wireshark and capture in
  promiscuous mode on Android by setting up a Debian chroot:
  http://balintreczey.hu/blog/run-wireshark-on-android-using-lil-debi/
 
  Cheers,
  Balint
 
  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  Archives:http://www.wireshark.org/lists/wireshark-dev
  Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
 
 
 
  --
 
  Pozdrawiam / Best regards
 
  -
  Michał Łabędzki, Software Engineer
  Tieto Corporation
 
  Product Development Services
 
  http://www.tieto.com / http://www.tieto.pl
  ---
  ASCII: Michal Labedzki
  location: Swobodna 1 Street, 50-088 Wrocław, Poland
  room: 5.01 (desk next to 5.08)
  ---
  Please note: The information contained in this message may be legally
  privileged and confidential and protected from disclosure. If the
  reader of this message is not the intended recipient, you are hereby
  notified that any unauthorised use, distribution or copying of this
  communication is strictly prohibited. If you have received this
  communication in error, please notify us immediately by replying to
  the message and deleting it from your computer. Thank You.
  ---
  Please consider the environment before printing this e-mail.
  ---
  Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
  Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
  Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
  Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON:
  812023656. Kapitał zakładowy: 4 271500 PLN

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




 --
 Thanks  Regards,
 Shashikant P. Ajegaonkar
 +91-8886889456
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Can we put android phone device connected over USB to Win 7 PC in promiscous mode?

[Bálint Réczey]

2015-02-24 8:13 GMT+01:00 Shashikant Ajegaonkar ajegaon...@gmail.com:
 Hi All,

 Has anyone tried to put WiFi interface of Android device in promiscous mode?
 Is it possible to enumerate phone over adb interface as device  wireless
 network interface in Win7 machine and configure it in promiscous mode for
 sniffer application?
It is not Win 7 related, but you can run Wireshark and capture in
promiscuous mode on Android by setting up a Debian chroot:
http://balintreczey.hu/blog/run-wireshark-on-android-using-lil-debi/

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] American Fuzzy Lop - Menagerie Minimization

[Bálint Réczey]

2015-01-25 15:41 GMT+01:00 Evan Huus eapa...@gmail.com:
 Gerald and I have (independently) started playing with the American
 Fuzzy Lop fuzzer recently [1] as a possibly more intelligent
 alternative or complement to our current fuzzing set-up.

 It includes a tool afl-cmin that uses its instrumentation to find
 unnecessary files in a set of inputs (i.e. files that don't exercise
 any new paths compared to the rest of the inputs). As an experiment, I
 ran this tool against tshark -nr on our currently available public
 menagerie folder and it cut it about in half.

 Before: 5726 files, 1.8G
 After: 2423 files, 764M

 I suspect with tshark -nxVr there are more paths and fewer
 duplicates (and it would also take a lot longer to run the script) but
 it may be worth investigating regardless. If anybody else is curious
 about the results I've made the minimized file list available at [2].
Cool, great job! :-)


 Cheers,
 Evan

 [1] http://lcamtuf.coredump.cx/afl/
 [2] https://dl.dropboxusercontent.com/u/171647/mini-menagerie
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Issues packaging Wireshark in Ubuntu

[Bálint Réczey]

Hi Juanjo,

2015-01-16 17:04 GMT+01:00 Juan Jose Martin Carrascosa jua...@rti.com:
 Hi all,

 I have a very quick question: am I supposed to create deb packages by doing
 make debian-package? The makefile doesn't recognize that option :(
No, by running dpkg-buildpackage -rfakeroot.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Questions about Submission of dissectors

[Bálint Réczey]

Hi,

2015-01-10 13:08 GMT+01:00 Pascal Quantin pascal.quan...@gmail.com:
 Hi Christopher,

 2015-01-09 21:51 GMT+01:00 Christopher Sheldahl
 christopher.sheld...@yahoo.com:

 My company has developed a number of dissectors for our own protocols, and
 we are interested in possibly having them incorporated into the main
 Wireshark distribution.

 We have a few questions related to this process.

 1) Could our dissectors be incorporated into the main Wireshark
 distribution after code review?


 Yes your dissectors can be incorporated once they pass the review stage.
 Please read
 https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcContribute.html for
 more details on the process. The patch should be done against master branch.



 2) Is there an official form for contributions, covering legal aspects?


 The source code must be under GPL 2.0.
I think GPL 2.0+ would be more future-proof.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-bugs] [Bug 10750] Use of GdkPixdata / gdk_pixbuf_new_from_inline deprecated in gdk-pixbuf 2.31.2

[Bálint Réczey]

2015-01-07 20:08 GMT+01:00 Stephen Fisher sfis...@sdf.org:
 On Wed, Jan 07, 2015 at 07:51:33PM +0100, B?lint R?czey wrote:

 Removing usages of the deprecated functions is on my TODO list, but if
 I can't finish that in reasonable time keeping the reminder would help
 others to act.

 What about leaving disabled functions deprecated in git and removing it
 from distribution source tarballs?  Gerald (at least used to) do this
 upon release for -Werror, for example:
 http://anonsvn.wireshark.org/viewvc?revision=22144view=revision
I use git snapshots to base the Debian packages on because it is the
(ideally) minimal set of files which Wireshark can be built from. It
is also a set of files with clean history without any pre-generated
additions.

Thus this change would not affect Debian packages.

Cheers,
Balint


 Deprecated functions are usually removed in a few releases and we
 should be prepared for the removal.

 If I remember correctly, GTK/GLib removes deprecated functions at the
 next major version.  The downside of not remembering to fix them along
 the way would be a lot of extra work when the next major version came
 out.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-bugs] [Bug 10750] Use of GdkPixdata / gdk_pixbuf_new_from_inline deprecated in gdk-pixbuf 2.31.2

[Bálint Réczey]

Hi Stephen,

2015-01-07 19:31 GMT+01:00 Stephen Fisher sfis...@sdf.org:
 On Wed, Jan 07, 2015 at 06:21:06PM +, bugzilla-dae...@wireshark.org wrote:
 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10750

 --- Comment #7 from Balint Reczey bal...@balintreczey.hu ---
 (In reply to Stephen Fisher from comment #6)
  Distribution sources really shouldn't disable deprecated functions like
  that; only developer ones should to remind us to update the functions.
  However Wireshark doesn't have an (easy) way to change that so I'm going to
  the remove -DDISABLE_DEPRECATED flag shortly as well as backporting it.

 Please don't do that. Distributions are free to patch out the
 deprecations and I regularly do that when it is needed for all Debian
 derivatives.

 But why should they have to?  And what about users who build from
 regular source distributions of Wireshark?  Developers using
 -DDISABLE_DEPRECATED just buys us a reminder when something suddenly
 becomes deprecated in a newer version by breaking it and waiting for a
 fix, but for users it causes headache trying to either remove that flag
 or downgrade the software (in this case gdk-pixbuf).  I had another
 piece of software get hit by this same problem last week, so I ended up
 going the lazy route and downgrading gdk-pixbuf.
IMO integration is the distributions' package maintainers job and
disabling such reminders is one of their decisions to make or not
make. I would prefer keeping them when wearing any of my Wireshark Dev
and my Debian Dev hats.
Removing usages of the deprecated functions is on my TODO list, but if
I can't finish that in reasonable time keeping the reminder would help
others to act.
Deprecated functions are usually removed in a few releases and we
should be prepared for the removal.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Update Windows Build Instructions

[Bálint Réczey]

Hi Stephen,

2015-01-06 0:20 GMT+01:00 Stephen Fisher sfis...@sdf.org:
 On Mon, Jan 05, 2015 at 03:34:16PM -0500, Ed Beroset wrote:

 Having been around this particular block a couple of times, yes, CMake
 at times is a battle, but it's also better than the alternative of
 producing (and maintaining) multiple mutually incompatible and
 inevitably arbitrarily different build systems in parallel.

 The beauty of autoconf/automake on Unix is that it spits out standard
 MakefileS so that normal users don't have to install a special program
 just to build the software.  I haven't tried Wireshark with CMake yet,
 but doesn't every user have to install it to build the software?  Or can
 cmake's output be included in source distributions so only developers
 need it?
Originally I was skeptical regarding CMake, but now I think this is
the best cross-platform option, thus the best option for Wireshark.
Just give it a try, and you will never look back. :-)

Theoretically autofoo creates ./configure and a proper makefile
system, but in reality the generated scripts get bitrot thus you
practically need autofoo everywhere.

New platforms for example don't have their gnu triplet in outdated
configure scripts.

Today the the best practice (IMO) is _not_ shipping configure, but
requiring autofoo/CMake in source tarballs.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Generate AUTHORS file

[Bálint Réczey]

2015-01-06 18:02 GMT+01:00  mman...@netscape.net:
 One thing I noticed when I reviewed one of the .mailman patches you've
 submitted was that some authors have multiple email addresses.  Do we really
 want to include them all?  I thought the current AUTHORS file typically only
 has one (hopefully latest email address)
I think when people move to a new company and they contributed on
behalf of or with the approval of their prior company the prior
company still deserves the credit.
Since credit is usually given by using the company's email address I
think retaining the old addresses is better.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] CMake status

[Bálint Réczey]

Hi,

2015-01-05 21:17 GMT+01:00 Gerald Combs ger...@wireshark.org:
 Our CMake environment has been coming along nicely. However, it's still
 missing several major build targets that are present in the Autotools
 and Nmake+QMake makefiles:

 dist. Balint created a script (tools/git-export-release.sh) which runs
 git archive. I'm not sure how complete it is compared to the current
 dist output.
For my use-case (packaging Wireshark for Debian) it is complete. I
think it is better than
make dist because the archive does not contain generated files which
are not stored in git.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Ubuntu PPA for Wireshark stable branch

[Bálint Réczey]

Hi,

2014-12-12 22:56 GMT+01:00 Evan Huus eapa...@gmail.com:
 Very cool, thanks Balint!

 Also on the topic of Ubuntu and Wireshark, it looks like the packages
 that ship with Ubuntu are finally getting some security love:
 https://bugs.launchpad.net/ubuntu/+source/wireshark/+bug/1397091
Great!


 Evan

 On Fri, Dec 12, 2014 at 4:53 PM, Bálint Réczey bal...@balintreczey.hu wrote:
 Hi All,

 I have created a PPA for the stable Wireshark branch point releases:
 https://launchpad.net/~wireshark-dev/+archive/ubuntu/stable

 The packages are back-ported from latest packaged version in Debian
 unstable to prevent upgrade problems.

 Since in Debian we are in freeze phase I can't upload 1.12.2-1, but
 when it is over in a few weeks I will follow the Wireshark releases
 closely again.

 It is not an official announcement, just a short status update. The
 packages are building on Launchpad for the first time and haven't been
 tested yet. If you feel so please try them and send feedback.

 Currently packages for Ubuntu 14.10 (Trusty) are building, and I plan
 adding all supported Ubuntu versions.
I have uploaded and tested the versions built for 14.04 and 12.04. For
now I don't plan providing a version for 10.04, because it is not
supported on desktop, but if there is a need for it it can be added
easily.

The scripts I used for packaging are available at
https://github.com/rbalint/pkg-wireshark-ubuntu-ppa .

I think we could make a formal announcement about it in a few days.
Gerald, would you like to announce the availability of the packages?

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Ubuntu PPA for Wireshark stable branch

[Bálint Réczey]

Hi All,

I have created a PPA for the stable Wireshark branch point releases:
https://launchpad.net/~wireshark-dev/+archive/ubuntu/stable

The packages are back-ported from latest packaged version in Debian
unstable to prevent upgrade problems.

Since in Debian we are in freeze phase I can't upload 1.12.2-1, but
when it is over in a few weeks I will follow the Wireshark releases
closely again.

It is not an official announcement, just a short status update. The
packages are building on Launchpad for the first time and haven't been
tested yet. If you feel so please try them and send feedback.

Currently packages for Ubuntu 14.10 (Trusty) are building, and I plan
adding all supported Ubuntu versions.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] --without-gtk3 doesn't imply --with-qt

[Bálint Réczey]

Hi Jeff,

2014-12-01 18:59 GMT+01:00 Jeff Morriss jeff.morriss...@gmail.com:
 On 11/29/14 05:44, Bálint Réczey wrote:

 Hi Jeff,

 2014-11-26 19:26 GMT+01:00 Jeff Morriss jeff.morriss...@gmail.com:

 On 11/26/14 13:01, Stephen Fisher wrote:


 Is there any reason a user would have both GTK3 and GTK2 installed and
 not want to use GTK3 for wireshark-gtk builds?  We could simplify it to
 be --with-gtk/--without-gtk and --with-qt/--without-qt and just use the
 latest version of GTK on the system (3.x, if available, otherwise 2.x)
 when requested.  The default could remain to make a Qt and GTK build and
 if the user didn't want GTK anymore, just pass --without-gtk to the
 configure script.



 I have both Gtk3 and Gtk2 installed but build with Gtk2.  The Gtk3 UI
 just
 looks horrible to me (and, no, I'm not one who really cares about how
 things
 look but, well, I have a choice).

 Could you please share a screenshot about what you find horrible in GTK3?
 I'm using the Debian package which looks quite good to me and I
 managed to get the OS X version to be nice as well:


 (I generally build on Fedora though what I push to my users is for
 RHEL/CentOS.)

 I think what really did it for me was the Decode-As window:

 https://www.wireshark.org/lists/wireshark-dev/201307/msg00198.html

 I can (still) barely tell which tab I'm on.
Yes, the active and inactive tabs look almost the same, because there
is no theme installed for GTK+ and the default look was pretty ugly.

Adwaita became the built-in standard theme from GTK+3.14 thus the default look
should change to something similar to what I attached on every system.



 http://balintreczey.hu/blog/beautiful-wireshark-on-os-x-using-homebrew-and-gtk3quartz/


 Looking at it more I think another thing that bothers me even on the home
 page is that the (disabled - because in my build environment I don't have
 capture privs) start capture now icon is green (but with a different color
 background) rather than, as in the Gtk2 or Qt versions, well, not green at
 all.
I can hardly fix that in GTK+3, it is the the icon shipped with Wireshark. :-)

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] CMake support out of source plugin compilation

[Bálint Réczey]

2014-11-20 9:53 GMT+01:00 Maarten Bezemer maarten.beze...@gmail.com:
 On Thursday 13 November 2014 15:15:26 you wrote:
 On Thursday 13 November 2014 13:56:26 Graham Bloice wrote:
  While I'm all for making life easier for devs, if no-one else has
  identified this as a need, i.e. only you find it worthwhile, then we will
  end up with stuff not generally used in the repo and then who will be
  maintaining these bits of CMake?

 [1] is an attempt I found to have out of source builds. But it never got fed
 back to Wireshark and consists (eventually) outdated scripts. By
 integrating such functionality, keeps the development scripts up-to-date.

 I am also willing to write a (wiki) document explaining the out of source
 builds (when my patches get accepted) to help out others as well. As the
 current information about this subject on the Internet is very minimal.

 The maintenance of my patches is not too hard I think. I mainly use (cmake)
 scripts that are already available. The changes I made are to make them more
 generic, e.g. by getting rid of hard-coded paths. All scripts are
 also/already used when Wireshark itself gets build.

 Is there anything left for me to do or to explain?
 I would like gain some momentum either direction (approved or abandoned), so I
 know whether my current (out of source) plug-in implementation can be used at
 work or not.
I was waiting for Jörg to comment on the change, but I have submitted
it instead:
https://code.wireshark.org/review/#/c/5316/

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Backporting policy for protocols that are under construction

[Bálint Réczey]

Hi,

2014-11-20 12:05 GMT+01:00 Alexis La Goutte alexis.lagou...@gmail.com:
 On Thu, Nov 20, 2014 at 5:03 AM, Evan Huus eapa...@gmail.com wrote:
 There is currently a change pending backport to the 1.12 branch (long
 since committed to master) that is a non-trivial dissector upgrade.
 Normally we don't backport this kind of change, to keep the regression
 potential to a minimum for stable releases, but this situation is
 somewhat unusual. The protocol in question was still being actively
 designed and developed when the 1.12 branch was created, so the
 dissector currently in the 1.12 branch implements a basically
 abandoned version of the spec that never ended up in serious use.

 I am ambivalent on this right now. I don't want to cause too much
 churn on the stable branch, but I can see the argument for backporting
 it regardless. It's also worth noting that while the protocol in
 question now is relatively narrowly focused, we will likely run into
 the exact same issue soon with HTTP2 which is rather more significant.

 What does everyone think? Should we be conservative and forbid this
 sort of thing? Permit it, but only after some extra level of
 testing/review? Other options?

 Thanks,
 Evan

 (The change in question is https://code.wireshark.org/review/4050 but
 I'm kind of looking for a more general resolution given that we're
 going to run into this problem again.)

 My opinion :
 When it is some minor change and don't need add/change a lot of code
 ( 250 lines ?), it will be ok
 Avoid to add/change some new header field (hf)

 in case of HTTP2, i waiting the final draft to backport fix (to be
 sure there is no new frame change...)
 When final draft will be available, will be no longer need a support
 of old draft (all implementation follow quicky the change on HTTP2
 spec)

 About https://code.wireshark.org/review/4050
 tfs change will be remove (it is a enhance for me), and also don't
 remove the if 0 (only add stuff for support last change)
Since our development builds are of very good quality people living on
the bleeding edge can use them without any problem.
I would prefer back-porting only very small and very important bug
fixes and no features because every back-port makes back-porting other
changes harder.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Conflicts: field in commit messages

[Bálint Réczey]

Hi,

2014-10-26 19:58 GMT+01:00 Bálint Réczey bal...@balintreczey.hu:
 2014-10-08 11:41 GMT+02:00 Michal Labedzki michal.labed...@tieto.com:
 On 7 October 2014 19:29, Guy Harris g...@alum.mit.edu wrote:
 2) somebody resolved the conflicts but forgot to edit the commit 
 message.

 I think this is wrong meaning  of this git feature. In my opinion
 Conflicts:  should not be deleted, because it is added by git after
 resolving conflicts, so it does not mean that file has conflicts but
 there were conflicts in specified files, they was solved, but this
 commit may be not compatible with original commit in these files
 (please note: there can be Conflicts: FILE_NAME on file that is not
 in commit. This is possible because conflicts can be solved in way
 that file is unchanged in that branch [quite often case])
 +1
I would like to keep the Conflicts: ... parts in the commit messages
the way git generates them automatically because IMO the widely
accepted interpretation and intended meaning is what Michal described.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark 1.12.2 is now available

[Bálint Réczey]

Hi Gerald,

2014-11-12 21:33 GMT+01:00 Gerald Combs ger...@wireshark.org:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I'm proud to announce the release of Wireshark 1.12.2.

  __

 What is Wireshark?

Wireshark is the world's most popular network protocol
analyzer. It is used for troubleshooting, analysis, development
and education.
  __

 What's New

   Bug Fixes

The following vulnerabilities have been fixed.
  * [1]wnpa-sec-2014-20
SigComp UDVM buffer overflow. ([2]Bug 10662)
[3]CVE-2014-8710
  * [4]wnpa-sec-2014-21
AMQP crash. ([5]Bug 10582) [6]CVE-2014-8711
  * [7]wnpa-sec-2014-22
NCP crashes. ([8]Bug 10552, [9]Bug 10628) [10]CVE-2014-8712
[11]CVE-2014-8713
  * [12]wnpa-sec-2014-23
TN5250 infinite loops. ([13]Bug 10596) [14]CVE-2014-8714

Thank you Gerald!

Debian testing has entered the freeze state thus I can't upload 1.12.2
to unstable.
Could you please create an lts-1.12.1 branch starting from 1.12.1?
I will maintain it like the other LTS branches.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] On which platforms is there a need for Wireshark to have a Language preference?

[Bálint Réczey]

Hi Dario,

2014-11-05 9:31 GMT+01:00 Dario Lombardo dario.lombardo...@gmail.com:
 Hi Guy
 The answer is yes. I live in italy, but I use linux in english. I switch to
 en or it for the specific purpose of the moment. With auto-detect I could't
 do that. For my daily use I switch to EN. To develop/test wireshark italian
 translation I switch to IT.

 I don't know if this scenario applies to others, but for me getting rid of a
 functionality that is still in place is not a good approach.
It sounds like a very atypical use-case.
Please run LC_ALL=it_IT wireshark instead of asking the project to
keep the language-switching feature.
The less code we maintain the better we can do it.

Cheers,
Balint


 Have a nice day.
 Dario.

 On Tue, Nov 4, 2014 at 8:34 PM, Guy Harris g...@alum.mit.edu wrote:

 I.e., are there reasons, on any platforms, to set the Language preference
 to anything other than Auto-Detect?  As far as I know, on all supported
 platforms (Windows, OS X, UN*Xes other than OS X) the Qt system locale gets
 the locale information from the appropriate place on the OS.  Is there ever
 a need to override your global language setting?

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] On which platforms is there a need for Wireshark to have a Language preference?

[Bálint Réczey]

Hi Pascal,

2014-11-05 11:30 GMT+01:00 Pascal Quantin pascal.quan...@gmail.com:


 2014-11-05 11:12 GMT+01:00 Michal Labedzki michal.labed...@tieto.com:

  Please run LC_ALL=it_IT wireshark

 Does it work on Windows? I do not remember to know anyone GUI
 application without option to change language by GUI. Do you know how
 to change locale after running application? (QEvent::LocaleChange ?)
 If this is not possible then dynamic change application language will
 be lost.


 +1. Most software I use allow me to manually override the language without
 messing with the environment variables. And here we are talking about a
 functionality we already have. Removing it would be a big loss in my
 opinion.
If it is important for many many users, I'm OK with keeping it.

Cheers,
Balint



  The less code we maintain the better we can do it.

 This is only true in case that we do not lose any feature (or user
 experience)

 On 5 November 2014 10:52, Bálint Réczey bal...@balintreczey.hu wrote:
  Hi Dario,
 
  2014-11-05 9:31 GMT+01:00 Dario Lombardo dario.lombardo...@gmail.com:
  Hi Guy
  The answer is yes. I live in italy, but I use linux in english. I
  switch to
  en or it for the specific purpose of the moment. With auto-detect I
  could't
  do that. For my daily use I switch to EN. To develop/test wireshark
  italian
  translation I switch to IT.
 
  I don't know if this scenario applies to others, but for me getting rid
  of a
  functionality that is still in place is not a good approach.
  It sounds like a very atypical use-case.
  Please run LC_ALL=it_IT wireshark instead of asking the project to
  keep the language-switching feature.
  The less code we maintain the better we can do it.
 
  Cheers,
  Balint
 
 
  Have a nice day.
  Dario.
 
  On Tue, Nov 4, 2014 at 8:34 PM, Guy Harris g...@alum.mit.edu wrote:
 
  I.e., are there reasons, on any platforms, to set the Language
  preference
  to anything other than Auto-Detect?  As far as I know, on all
  supported
  platforms (Windows, OS X, UN*Xes other than OS X) the Qt system locale
  gets
  the locale information from the appropriate place on the OS.  Is there
  ever
  a need to override your global language setting?
 
 
  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  Archives:http://www.wireshark.org/lists/wireshark-dev
  Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
 
 
 
 
  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  Archives:http://www.wireshark.org/lists/wireshark-dev
  Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
 
  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  Archives:http://www.wireshark.org/lists/wireshark-dev
  Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe



 --

 Pozdrawiam / Best regards

 -
 Michał Łabędzki, Software Engineer
 Tieto Corporation

 Product Development Services

 http://www.tieto.com / http://www.tieto.pl
 ---
 ASCII: Michal Labedzki
 location: Swobodna 1 Street, 50-088 Wrocław, Poland
 room: 5.01 (desk next to 5.08)
 ---
 Please note: The information contained in this message may be legally
 privileged and confidential and protected from disclosure. If the
 reader of this message is not the intended recipient, you are hereby
 notified that any unauthorised use, distribution or copying of this
 communication is strictly prohibited. If you have received this
 communication in error, please notify us immediately by replying to
 the message and deleting it from your computer. Thank You.
 ---
 Please consider the environment before printing this e-mail.
 ---
 Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
 Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
 Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
 Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON:
 812023656. Kapitał zakładowy: 4 271500 PLN

 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http

Re: [Wireshark-dev] Updating debian symbols?

[Bálint Réczey]

Hi Anders,

2014-10-30 17:49 GMT+01:00 Anders Broman anders.bro...@ericsson.com:
 Hi,

 How to update the symbols file?
The output of the dpkg-gensymbols command includes the patch which
should be applied,

Whenever a new symbol is exported/removed the symbols file must be updated.
This reminds us to keep the API stable :-)

Cheers,
Balint


 dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see
 diff output below

 dpkg-gensymbols: warning: debian/libwireshark0/DEBIAN/symbols doesn't match
 completely debian/libwireshark0.symbols

 --- debian/libwireshark0.symbols (libwireshark0_1.99.1_amd64)

 +++ dpkg-gensymbols3gHR2l  2014-10-30 16:27:03.188650385 +

 @@ -83,6 +83,7 @@

   call_dissector_only@Base 1.9.1

   call_dissector_with_data@Base 1.9.1

   call_heur_dissector_direct@Base 1.12.0~rc1

 + call_per_oid_callback@Base 1.99.1

   camelSRTtype_naming@Base 1.9.1

   camel_opr_code_strings@Base 1.9.1

   capture_ap1394@Base 1.9.1

 @@ -319,6 +320,7 @@

   dissect_ndr_uuid_t@Base 1.9.1

   dissect_nt_64bit_time@Base 1.9.1

   dissect_nt_64bit_time_ex@Base 1.99.0

 + dissect_nt_64bit_time_opt@Base 1.99.1

   dissect_nt_sid@Base 1.9.1

   dissect_per_BMPString@Base 1.9.1

   dissect_per_GeneralString@Base 1.9.1

 @@ -762,6 +764,7 @@

   new_register_ber_oid_dissector@Base 1.99.1

   new_register_ber_syntax_dissector@Base 1.99.1

   new_register_dissector@Base 1.9.1

 + new_register_per_oid_dissector@Base 1.99.1

   next_tvb_add_handle@Base 1.9.1

   next_tvb_add_string@Base 1.9.1

   next_tvb_add_uint@Base 1.9.1

 @@ -1207,6 +1210,7 @@

   tfs_accepted_not_accepted@Base 1.9.1

   tfs_ack_nack@Base 1.9.1

   tfs_active_inactive@Base 1.9.1

 + tfs_allocated_by_receiver_sender@Base 1.99.1

   tfs_allow_block@Base 1.9.1

   tfs_allowed_not_allowed@Base 1.9.1

   tfs_available_not_available@Base 1.9.1

 dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see
 diff output below

 dpkg-gensymbols: warning: some symbols or patterns disappeared in the
 symbols file: see diff output below

 dpkg-gensymbols: warning: debian/libwsutil0/DEBIAN/symbols doesn't match
 completely debian/libwsutil0.symbols

 --- debian/libwsutil0.symbols (libwsutil0_1.99.1_amd64)

 +++ dpkg-gensymbolstRiJGi  2014-10-30 16:27:04.580730076 +

 @@ -139,8 +139,8 @@

   sober128_read@Base 1.99.0

   sober128_start@Base 1.99.0

   started_with_special_privs@Base 1.10.0

 - strnatcasecmp@Base 1.12.0~rc1

 - strnatcmp@Base 1.12.0~rc1

 +#MISSING: 1.99.1# strnatcasecmp@Base 1.12.0~rc1

 +#MISSING: 1.99.1# strnatcmp@Base 1.12.0~rc1

   test_for_directory@Base 1.12.0~rc1

   test_for_fifo@Base 1.12.0~rc1

   type_util_gdouble_to_guint64@Base 1.10.0

 @@ -156,6 +156,8 @@

   update_crc10_by_bytes@Base 1.10.0

   update_crc6_by_bytes@Base 1.10.0

   ws_add_crash_info@Base 1.10.0

 + ws_ascii_strnatcasecmp@Base 1.99.1

 + ws_ascii_strnatcmp@Base 1.99.1

   ws_base64_decode_inplace@Base 1.12.0~rc1

   ws_buffer_append@Base 1.99.0

   ws_buffer_assure_space@Base 1.99.0

 dh_makeshlibs: dpkg-gensymbols -plibwsutil0 -Idebian/libwsutil0.symbols
 -Pdebian/libwsutil0
 -edebian/libwsutil0/usr/lib/x86_64-linux-gnu/libwsutil.so.0.0.0

 returned exit code 1

 make: *** [binary] Error 1

 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
 status 2

 program finished with exit code 2

 elapsedTime=531.424488




 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Conflicts: field in commit messages

[Bálint Réczey]

2014-10-08 11:41 GMT+02:00 Michal Labedzki michal.labed...@tieto.com:
 On 7 October 2014 19:29, Guy Harris g...@alum.mit.edu wrote:
 2) somebody resolved the conflicts but forgot to edit the commit 
 message.

 I think this is wrong meaning  of this git feature. In my opinion
 Conflicts:  should not be deleted, because it is added by git after
 resolving conflicts, so it does not mean that file has conflicts but
 there were conflicts in specified files, they was solved, but this
 commit may be not compatible with original commit in these files
 (please note: there can be Conflicts: FILE_NAME on file that is not
 in commit. This is possible because conflicts can be solved in way
 that file is unchanged in that branch [quite often case])
+1
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] 25 Warnings on Clang Scan Build

[Bálint Réczey]

2014-10-14 21:41 GMT+02:00 Alexis La Goutte alexis.lagou...@gmail.com:
 Hi,

 For the first time, you are under 25 warnings on Clang scan-build :-D
 ( https://www.wireshark.org/download/automated/analysis/ )

 A quick review about last warnings :
 3 coming from flex (Dead Assignement on ascend_scanner.c, k12text.c,
 ascend.c), need to fix flex on upstream...


 10 coming from lemon (sqlite), i have start to update lemon from
 upstream ( https://code.wireshark.org/review/#/c/3976/ ) but all
 warning is no fixed...

 and last warning is Dereference of null pointer not yet look all
 warning but some warning is false postive (packet-ber...)
Great news!

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Conflicts: field in commit messages

[Bálint Réczey]

Hi Guy,

2014-10-07 19:29 GMT+02:00 Guy Harris g...@alum.mit.edu:

 On Oct 7, 2014, at 1:12 AM, Michal Labedzki michal.labed...@tieto.com wrote:

 You miss one thing - cherry-pick with conflicts is not the same that
 original commit.

 That's what with manual intervention is for, as per my earlier message.

 It may build and work in 99% cases of original use,
 but may file because one conflicts can be not correctly resolved.

 Presumably fail means fail at run time rather than fail to build.

 When I see Conflicts: in a commit message, it reads to *me* as if either

 1) somebody forgot to resolve the conflicts and is committing the 
 broken result
Since our policy is not committing something which does not build and
in the future it will be enforced automatically you can't see the
message in master / or in an other branch.


 or

 2) somebody resolved the conflicts but forgot to edit the commit 
 message.
With our current practice this would be the most probable case.
I think however keeping them in the message instead of replacing them
with  with manual intervention would save some work and keep more
information

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Conflicts: field in commit messages

[Bálint Réczey]

Hi All,

I usually leave the Conflicts: ... in the commit message after
resolving conflicts to document that the merge was not automatic.
Should I continue doings so you prefer removing this from the commit message?
Guy raised the issue in https://code.wireshark.org/review/#/c/4438 ,
but I think the question deserves more attention than being just a
valid code-review comment.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Planet.wireshark.org?

[Bálint Réczey]

Hi,

We had some discussions about blogging more actively on
https://blog.wireshark.org/, but I think there would be an other way
of making the project more active on the press side.
We have a nice community and we could provide and site for aggregating
Wireshark-related news from individual bloggers.
Some of us already have blogs which could be added as sources and I'm
pretty sure others would be interested, too.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master bcae048: Update to the latest version from the Samba Git repository.

[Bálint Réczey]

Hi,

2014-09-26 21:12 GMT+02:00 Evan Huus eapa...@gmail.com:
 Since it looks like PIDL is also using git, how do people feel about
 using git submodules instead of maintaining our own copy of PIDL?
I would avoid submodules because it adds a lot of complexity without
providing little value.
If we would like to depend on external projects' files we don't want
to store in our source we can add them to build tools.

Cheers,
Balint


 On Fri, Sep 26, 2014 at 3:02 PM, Wireshark code review
 code-review-do-not-re...@wireshark.org wrote:
 URL: 
 https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=bcae0488fc09cbb264b1a816be74e5e0721847b3
 Submitter: Guy Harris (g...@alum.mit.edu)
 Changed: branch: master
 Repository: wireshark

 Commits:

 bcae048 by Guy Harris (g...@alum.mit.edu):

 Update to the latest version from the Samba Git repository.

 From the Samba log:

 commit bfdc874e8b98c8ea147dbcc986f96ad4f73d800f
 Author: Jelmer Vernooij jel...@samba.org
 Date:   Sat Aug 30 01:59:26 2014 +0200

 Various updates to the pidl README file.

 Remove samba3/samba4-specific comments, add comments about backends 
 and files.

 Change-Id: Id2253ce85eab7a684b2c50d25f6f2604dc146a8e
 Signed-Off-By: Jelmer Vernooij jel...@samba.org
 Reviewed-by: David Disseldorp dd...@samba.org

 Autobuild-User(master): David Disseldorp dd...@samba.org
 Autobuild-Date(master): Sun Aug 31 23:47:49 CEST 2014 on sn-devel-104

 commit 6824f1aa67f0a75df5c94921e334c2b7c7771611
 Author: Jelmer Vernooij jel...@samba.org
 Date:   Sat Aug 30 01:59:25 2014 +0200

 Remove trailing whitespace.

 Change-Id: I1e0948da34bac278edc62cd63dedd08112426e7a
 Signed-Off-By: Jelmer Vernooij jel...@samba.org
 Reviewed-by: David Disseldorp dd...@samba.org

 Change-Id: Ifd445bf32aca2d30a6e501fc8c8dd030471ad284
 Reviewed-on: https://code.wireshark.org/review/4312
 Reviewed-by: Guy Harris g...@alum.mit.edu


 Actions performed:

 from  c90acf2   Qt: Capture fixes.
 adds  bcae048   Update to the latest version from the Samba Git 
 repository.


 Summary of changes:
  tools/pidl/README |   35 ++-
  1 file changed, 18 insertions(+), 17 deletions(-)
 ___
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Systematic crash at startup when launching Wireshark GTK+ 1.99 x64 on Windows 8.1

[Bálint Réczey]

Hi,

2014-09-16 8:24 GMT+02:00 Anders Broman a.broma...@gmail.com:

 Den 16 sep 2014 08:00 skrev Pascal Quantin pascal.quan...@gmail.com:




 Le 15 sept. 2014 23:13, Gerald Combs ger...@wireshark.org a écrit :

 
  On 9/15/14 10:51 AM, Gerald Combs wrote:
   On 9/15/14 10:02 AM, Pascal Quantin wrote:
  
   It explains why it works fine with 1.12.0 then... And why I could not
   figure out a major difference in main.c file explaining the behavior
   while using the same libraries!
  
   If I build a package from g0a24908 (the commit prior to the GTK+
   package
   upgrade) Wireshark-gtk.exe starts up OK.
 
  I created a GTK+ bundle using the current OBS packages (GTK+ 2.24.23 +
  GLib 2.40.0) but Wireshark-gtk still crashes on Windows 8. We might have
  to revert back to the GTK+ 2.14 bundle or to Visual C++ 2010 in master.

 If we have no other choice I would prefer downgrading the GTK+ package as
 it will become obsolete with time. And I would not have to reinstall a
 MSVC2010 build environment... But I'm probably selfish ;)

 Upgrading to this package solved a severe memory leak with windows server
 and RDP, I think.
 Not sure what the best of two evils are...
I think testing GTK+ 3.14 would worth a try when it is out. The
default theme will be changed to Adwaita so Wireshark on Windows and
OS X would become nice for free*:
https://blogs.gnome.org/mclasen/2014/06/13/a-new-default-theme-for-gtk/

Cheers,
Balint

* OK, not for free, but for cheap. :-)
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Qt License Change

[Bálint Réczey]

Hi,

2014-08-20 18:36 GMT+02:00 ronnie sahlberg ronniesahlb...@gmail.com:
 I think the biggest gotcha with LGPLv3 is that it is no longer
 compatible with GPLv2 only code.
 Wireshark does not have any GPLv2only code right? If not, we should be ok.

 On Wed, Aug 20, 2014 at 9:31 AM, Evan Huus eapa...@gmail.com wrote:
 http://blog.qt.digia.com/blog/2014/08/20/adding-lgpl-v3-to-qt/

 I don't *think* this affects us, but I haven't thought about it too hard.
I think this license change may be problematic for companies
distributing Wireshark with new LGPLv3-covered Qt if they don't want
to share their patents covering Qt for free (due to LGPLv3's patent
clause).

Disclaimer: I'm not a lawyer and this is not a legal advice.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Buildbot Man Page Generation

[Bálint Réczey]

Hi Evan,

2014-08-10 4:41 GMT+02:00 Evan Huus eapa...@gmail.com:
 http://buildbot.wireshark.org/trunk/builders/Clang%20Code%20Analysis/builds/2911/steps/check-abi/logs/stdio

 I took a quick look at the recent check-abi buildbot failure, which
 appears to be manpage related:

 wireshark.pod around line 3525: Non-ASCII character seen before
 =encoding in 'KovEaacuteř'. Assuming UTF-8
 POD document had syntax errors at /usr/bin/pod2man line 71.

 Which is curious, because wireshark.pod.template *does* have an
 =encoding line...

 Also of note is that we appear to be passing --title=The Wireshark
 Network Analyzer 1.8.2 to the generator on trunk, which is just
 wrong.

 Anybody know what's going on?
This is the lts-1.8.2 branch but the builds are shown on trunk's buildbot.
I updated the LTS branches before releasing the update to Debian in a
hope that the patched could be fuzz-tested by the buildbots, but I
think LTS branches are not fuzz-tested.
I have fixed a few build problems along the security fixes, but did
not have time to fix this one, too.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-announce] Wireshark 1.12.0rc3 is now available

[Bálint Réczey]

2014-07-31 10:32 GMT+02:00 Guy Harris g...@alum.mit.edu:

 On Jul 31, 2014, at 1:18 AM, Bálint Réczey bal...@balintreczey.hu wrote:

 Since the files stored in git are enough for building Wireshark on
 every platform we support

 So we shouldn't bother generating or shipping tarballs at all, just say 
 check out this from git if you want the 1.X.Y source?
Functionally a signed git tag is as good as a signed tarball, but
serving .xz compressed relesea tarballs are cheaper in terms of CPU
and bandwidth consumption, so I would go with that.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-announce] Wireshark 1.12.0rc3 is now available

[Bálint Réczey]

2014-07-31 12:34 GMT+02:00 Peter Wu pe...@lekensteyn.nl:
 On Wednesday 30 July 2014 14:35:06 Gerald Combs wrote:
 After comparing the tarballs generated by make dist and
 git-export-release.sh I have to agree. Both have issues but the dist
 tarball will build according to our documentation on Linux, Windows, and
 OS X.

 make dist is missing:
   - Quite a bit under asn1. asn1/*/CMakeLists.txt, gnm, gprscdr,
 and other assorted files.
   - Several CMake modules
   - Many files under debian
   - Many docbook files
   - Several READMEs in doc
   - Many files in plugins
   - Most (all?) files in tools

 git-export-release.sh is missing:
   - ./configure, install-sh, other Autotoolery
   - Files generated using Bison/Flex
   - help/faq.txt
   - packaging/macosx/Info.plist
   - plugins/*/plugin.c
   - ui/*/*shark-tap-register.c

 It looks like you can't build from a dist tarball using CMake which is
 something we should fix.

 Instead of relying on autotools to generate the distribution tarball, one
 could also (temporarily) add all generated files to git and use git to build
 the tarball.

 Something like this (ensure that you have no other files in your git tree!):

 git clean -xfd # Ensure clean working dir (destructive!)
 ./autogen.sh
 ./configure
 find -name Makefile* -print0 | xargs -0 git add -f
 git add ... configure, config.status, bison, flex, etc...
 git commit -q -m Release
 git archive --prefix=... HEAD | xz -9  tar.gz
 git reset --hard HEAD~ # Return to previous version
Please don't do that.


 Another thing to consider is the availability of cmake which does not require
 additional files in a distribution tarball like autotools. If all platforms
 support cmake, what about dropping the autotools-generated stuff?
+1 for dropping autotools in favor of CMake. CMake already covers all
my use cases.
I also support dropping nmake, but since I'm not building on Windows I
can't tell if CMake is complete enough.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] tvb allocator (was: Re: [Wireshark-commits] master b6d20a2: Optimize reseting epan_dissect_t when filtering.)

[Bálint Réczey]

Hi Jakub,

2014-07-22 0:52 GMT+02:00  darkjames...@darkjames.pl:
 Hi,

 On Sat, Jul 12, 2014 at 02:27:06AM +0200, B??lint R??czey wrote:
 I plan using ASAN for all programs which would catch (among others)
 use-after-free and reading below or over the malloc()-ed
 memory area. Those can't be caught if the program uses another layer
 of bulk memory allocations.
 g_malloc() and g_slice_* has the same problem, but they can be
 overrideb by passing G_SLICE=always-malloc .

 We have these environment variables also, ver{3, 4} introduce 
 WIRESHARK_DEBUG_WMEM_OBJECT_POOL_SKIP,
 where you can set, and object pool will not maintain free list of objects.

 I see no problem with enabling it by default when building with ASAN.

 Also it should be quite easy to use ASAN manual poisoning[1] with object pool 
 API.

 wmem_object_pool_alloc(wmem_allocator_t *allocator, wmem_object_pool_t *pool):
 if (pool-current_count  0) {
 ...
 ASAN_UNPOISON_MEMORY_REGION(pool-free_list, pool-object_size);
 pool-free_list = pool-free_list-next;

 wmem_object_pool_free(wmem_allocator_t *allocator, wmem_object_pool_t *pool, 
 void *ptr)
 ...
 ASAN_POISON_MEMORY_REGION(ptr, pool-object_size);

 (not tested).
Thank you, I was not aware of those macros. I think we should add
those to the custom allocator code.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] 1.12 release schedule

[Bálint Réczey]

Hi Gerald,

2014-07-22 0:19 GMT+02:00 Gerald Combs ger...@wireshark.org:
 I plan to release 1.12.0rc3 tomorrow (the 22nd) followed by 1.12.0 on
 the 29th. If we need to hold off either release for any reason please
 let me know.
Great!
I would like to have the fix for 9891 included which I plan reviewing today.


 Until now release candidate tags have been preceded by a hyphen, e.g.
 v1.10.0-rc1. As noted in change 2759 this causes a problem for RPM and
 Debian packaging so I plan to drop the hyphen.
Using v1.10.0rc1 creates an other problem. It is considered to be a
lower version number than v1.10.0:

$ dpkg --compare-versions 1.10.0rc1 ge 1.10.0
$ echo $?
0

In Debian packaging we use git tags like 1.10.0_rc1 and convert them
to version 1.10.0~rc1 in scripts and in debian/changelog.


Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] tvb allocator (was: Re: [Wireshark-commits] master b6d20a2: Optimize reseting epan_dissect_t when filtering.)

[Bálint Réczey]

Hi All,

Please provide the input data for letting others reproduce the results
or perform the performance tests on pcap files already available to
the public.

I'm not a fan of implementing custom memory management methods because
partly because I highly doubt we can beat jemalloc easily on
performance and custom allocation methods can also have nasty bugs
like the one observed in OpenSSL:
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

I wrote a short post about making all programs in Debian resistant to
malloc() related attacks using ASAN and wmem in its current form
prevents implementing the protection:
http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian/

Please don't sacrifice protection for 2% speedup. Please keep wmem
usage for cases where it is used for garbage collecting (free() after
end of frame/capture file) not when the allocation and deallocation
are already done properly.

Thanks,
Balint

2014-07-11 8:58 GMT+02:00 Jakub Zawadzki darkjames...@darkjames.pl:
 Hi,

 On Sat, Jun 21, 2014 at 10:12:48PM +0200, Jakub Zawadzki wrote:
 If we're in topic of optimizing 'slower' [de]allocations in common functions:

 - tvb allocation/deallocation (2.5%, or 3.4% when no filtering)

243,931,671  *  ???:tvb_new 
 [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0]
202,052,290 ???:g_slice_alloc (2463493x) 
 [/usr/lib64/libglib-2.0.so.0.3600.4]

291,765,126  *  ???:tvb_free_chain 
 [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0]
256,390,635 ???:g_slice_free1 (2435843x) 
 [/usr/lib64/libglib-2.0.so.0.3600.4]

 This, or next week I'll try to do tvb.

 ... or maybe this week:

 ver0 | 18,055,719,820 (---) | Base version 
 96f0585268f1cc4e820767c4038c10ed4915c12a
 ver1 | 18,185,185,838 (0.6% slower) | Change tvb allocator g_slice_* to wmem 
 with file scope
 ver2 | 17,809,433,204 (1.4% faster) | Change tvb allocator g_slice_* to wmem 
 with file/packet scope
 ver3 | 17,812,128,887 (1.3% faster) | Change tvb allocator g_slice_* to 
 simple object allocator with epan scope
 ver4 | 17,704,132,561 (2.0% faster) | Change tvb allocator g_slice_* to 
 simple object allocator with file scope

 I have uploaded patches  profiler outputs to: 
 http://www.wireshark.org/~darkjames/tvb-opt-allocator/

 Please review, and check what version is OK to be applied.


 P.S: I'll might find some time to do ver5 with slab allocator, but it'll look 
 like object allocator API with epan scope.

 Cheers,
 Jakub.
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] tvb allocator (was: Re: [Wireshark-commits] master b6d20a2: Optimize reseting epan_dissect_t when filtering.)

[Bálint Réczey]

Hi Evan,

2014-07-11 23:51 GMT+02:00 Evan Huus eapa...@gmail.com:
 On Fri, Jul 11, 2014 at 5:12 PM, Bálint Réczey bal...@balintreczey.hu
 wrote:

 Hi All,

 Please provide the input data for letting others reproduce the results
 or perform the performance tests on pcap files already available to
 the public.

 I'm not a fan of implementing custom memory management methods because
 partly because I highly doubt we can beat jemalloc easily on
 performance


 The only place we reliably beat jemalloc (or even glib) is when we have a
 large number of allocations that live together, and can be freed with
 free_all. Anything else is basically noise. As Jakub's test noted, the main
 block allocator is actually slightly slower than g_slice_* if the frees are
 done manually.


 and custom allocation methods can also have nasty bugs
 like the one observed in OpenSSL:
 http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

 I wrote a short post about making all programs in Debian resistant to
 malloc() related attacks using ASAN and wmem in its current form
 prevents implementing the protection:

 http://balintreczey.hu/blog/proposing-amd64-hardened-architecture-for-debian/


 It's not clear to me from reading the blog post or the mail to debian what
 the actual protections would be, or why wmem would prevent them from
 working. Could you clarify please? Glib has its own allocator logic
 internally for g_slice_*, does this also cause problems?
I plan using ASAN for all programs which would catch (among others)
use-after-free and reading below or over the malloc()-ed
memory area. Those can't be caught if the program uses another layer
of bulk memory allocations.
g_malloc() and g_slice_* has the same problem, but they can be
overrideb by passing G_SLICE=always-malloc .

I know wmem has simple allocator, but wmem_free() is really
inefficient and as a fix I would like to propose removing wmem_free()
from the API.
IMO Wireshark needs wmem_alloc() for allocating and freeing memory
needed during whole scopes, but should not offer wmem_free() and
wmem_realloc() to let us able to provide efficient per-scope
allocations. Dissectors which should simply do g_malloc()/g_free() for
allocations when they know when they need to free memory and using
wmem_free() also does not keep the promise of having a
wmem_alloc()-ated object available during the whole scope.

Wmem also have a lot of data structures reimplemented using
wmem-backed memory, but I think it would be way easier to use GLists
registered to be g_list_free()-d using wmem_register_callback() than
using wmem_list_* functions for manipulating per-scope allocated lists
for example.

Cheers,
Balint



 Please don't sacrifice protection for 2% speedup. Please keep wmem
 usage for cases where it is used for garbage collecting (free() after
 end of frame/capture file) not when the allocation and deallocation
 are already done properly.

 Thanks,
 Balint

 2014-07-11 8:58 GMT+02:00 Jakub Zawadzki darkjames...@darkjames.pl:
  Hi,
 
  On Sat, Jun 21, 2014 at 10:12:48PM +0200, Jakub Zawadzki wrote:
  If we're in topic of optimizing 'slower' [de]allocations in common
  functions:
 
  - tvb allocation/deallocation (2.5%, or 3.4% when no filtering)
 
 243,931,671  *  ???:tvb_new
  [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0]
 202,052,290 ???:g_slice_alloc (2463493x)
  [/usr/lib64/libglib-2.0.so.0.3600.4]
 
 291,765,126  *  ???:tvb_free_chain
  [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0]
 256,390,635 ???:g_slice_free1 (2435843x)
  [/usr/lib64/libglib-2.0.so.0.3600.4]
 
  This, or next week I'll try to do tvb.
 
  ... or maybe this week:
 
  ver0 | 18,055,719,820 (---) | Base version
  96f0585268f1cc4e820767c4038c10ed4915c12a
  ver1 | 18,185,185,838 (0.6% slower) | Change tvb allocator g_slice_* to
  wmem with file scope
  ver2 | 17,809,433,204 (1.4% faster) | Change tvb allocator g_slice_* to
  wmem with file/packet scope
  ver3 | 17,812,128,887 (1.3% faster) | Change tvb allocator g_slice_* to
  simple object allocator with epan scope
  ver4 | 17,704,132,561 (2.0% faster) | Change tvb allocator g_slice_* to
  simple object allocator with file scope
 
  I have uploaded patches  profiler outputs to:
  http://www.wireshark.org/~darkjames/tvb-opt-allocator/
 
  Please review, and check what version is OK to be applied.
 
 
  P.S: I'll might find some time to do ver5 with slab allocator, but it'll
  look like object allocator API with epan scope.
 
  Cheers,
  Jakub.
 
  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  Archives:http://www.wireshark.org/lists/wireshark-dev
  Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

 ___
 Sent via:Wireshark-dev mailing list wireshark

Re: [Wireshark-dev] tvb allocator (was: Re: [Wireshark-commits] master b6d20a2: Optimize reseting epan_dissect_t when filtering.)

[Bálint Réczey]

2014-07-12 0:07 GMT+02:00 Anders Broman a.broma...@gmail.com:

 Den 11 jul 2014 23:13 skrev Bálint Réczey bal...@balintreczey.hu:



 Hi All,

 Please provide the input data for letting others reproduce the results
 or perform the performance tests on pcap files already available to
 the public

 Ok I'll see if we can use something from the wiki instead.


 I'm not a fan of implementing custom memory management methods because
 partly because I highly doubt we can beat jemalloc easily on
 performance and custom allocation methods can also have nasty bugs
 like the one observed in OpenSSL:
 http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse


 We have gone through a set of memory allocation schemes already to try to
 improve performance (g_slice, emen and now wmem) are you saying that you are
 opposed to that?
No, IMO there is need for wmem for being able to keep memory allocated
during scopes,
but I would prefer seeing it only tracking and one-by-one freeing the
memory areas instead of doing bulk alloc()-s for optimizing for speed.

I tried to detail this in my answer to Evan's email.


 As wmem seems to be the faster scheme for packet scope memory allocation
 /free, why not use it in all possible places where  the scope is packet?

 Please don't sacrifice protection for 2% speedup. Please keep wmem
 usage for cases where it is used for garbage collecting (free() after
 end of frame/capture file) not when the allocation and deallocation
 are already done properly.

 ? A slow scheme might be working well but that in it self does not warrant
 to not replace it with a faster one. With this reasoning we shouldn't have
 introduced ep memory in the first place.

 What percentage if improvement do you think makes a change worthwhile?

 The set of improvements Jacub and I have done lately has given a reduction
 of 40-50 percent compared to 1.10 measuring with the sample file. The
 problem is that each improvement only yeald a percent or 2. Agreed that we
 shouldn't complicate the code for a small speed gain.
40-50% reduction is great and congratulations for such a speedup!
I hope memory allocation handling is responsible for only small
fraction of it because I would like to keep the possibility of
detecting memory allocation related errors and I would prefer using
tools implemented outside of Wireshark.
For example I would avoid bulk allocations to make us able to use ASAN
and Valgrind, even if we would implement our canaries.


 In your blog you say that people would accept double the execution time with
 increased security - I'm not so sure. If say the reformatting of a video
 takes one hour instead of 30 minutes.
In Debian you would be able to pick a slow and secure video player for
streaming from the untrusted Internet and a fast and less secure video
encoder.
I expect people to install Wireshark from the hardened-amd64
repository if they want to monitor a hostile network, while others
pick the fast Wireshark for using it in their safe labs.
So it depends and there will be good options to choose from.

Cheers,
Balint


 Just my 2 cents
 Anders


 Thanks,
 Balint

 2014-07-11 8:58 GMT+02:00 Jakub Zawadzki darkjames...@darkjames.pl:
  Hi,
 
  On Sat, Jun 21, 2014 at 10:12:48PM +0200, Jakub Zawadzki wrote:
  If we're in topic of optimizing 'slower' [de]allocations in common
  functions:
 
  - tvb allocation/deallocation (2.5%, or 3.4% when no filtering)
 
 243,931,671  *  ???:tvb_new
  [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0]
 202,052,290 ???:g_slice_alloc (2463493x)
  [/usr/lib64/libglib-2.0.so.0.3600.4]
 
 291,765,126  *  ???:tvb_free_chain
  [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0]
 256,390,635 ???:g_slice_free1 (2435843x)
  [/usr/lib64/libglib-2.0.so.0.3600.4]
 
  This, or next week I'll try to do tvb.
 
  ... or maybe this week:
 
  ver0 | 18,055,719,820 (---) | Base version
  96f0585268f1cc4e820767c4038c10ed4915c12a
  ver1 | 18,185,185,838 (0.6% slower) | Change tvb allocator g_slice_* to
  wmem with file scope
  ver2 | 17,809,433,204 (1.4% faster) | Change tvb allocator g_slice_* to
  wmem with file/packet scope
  ver3 | 17,812,128,887 (1.3% faster) | Change tvb allocator g_slice_* to
  simple object allocator with epan scope
  ver4 | 17,704,132,561 (2.0% faster) | Change tvb allocator g_slice_* to
  simple object allocator with file scope
 
  I have uploaded patches  profiler outputs to:
  http://www.wireshark.org/~darkjames/tvb-opt-allocator/
 
  Please review, and check what version is OK to be applied.
 
 
  P.S: I'll might find some time to do ver5 with slab allocator, but it'll
  look like object allocator API with epan scope.
 
  Cheers,
  Jakub.
 
  ___
  Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
  Archives:http://www.wireshark.org/lists/wireshark-dev
  Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

Re: [Wireshark-dev] Fwd: Re: Storing Generated Code in Git [Was: master 9079e3a: Cheat and try to fix the generated file manually.]

[Bálint Réczey]

2014-06-24 5:26 GMT+02:00 Joerg Mayer jma...@loplof.de:
 On Mon, Jun 23, 2014 at 09:17:32PM -0400, Evan Huus wrote:
   So perhaps what we should do is:
  
   not check generated code into Git;
+1

  
   put all generated code into the source tarballs.

 +2
How about releasing two tarballs, one with and one without the generated files?
We could count the downloads.

Cheers,
Balint


  Presumably we should rebuild all the DCERPC files as well at buildtime
  then?

 YEs, once we have a version in our source that is actually capable of doing 
 that.
 It doesn't build all files for me.

 If that's possible, yes. I don't actually know how to generate them, so I
 don't know how fast and/or cross-platform it is.

 See epan/dissectors/pidl/README on how to do that in tree (in theory).

 Ciao
Jörg


 --
 Joerg Mayer   jma...@loplof.de
 We are stuck with technology when what we really want is just stuff that
 works. Some say that should read Microsoft instead of technology.
 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-commits] master 9079e3a: Cheat and try to fix the generated file manually.

[Bálint Réczey]

Hi,

2014-06-23 17:54 GMT+02:00 Evan Huus eapa...@gmail.com:
 I would *really* prefer we didn't do this.
Me, too. Going this way makes maintaining Wireshark really hard. And
for 1% speed increase in a very specific case?
I generally don't agree with the approach and in this specific IMO the
gains did not justify the introduction of an automatically generated,
then manually slightly modified file.

I would also like to ask everyone to not rush merging changes without
discussion to master. I usually wait one day or two for comments
before merging a review opened by me, sometimes more if others may
have very different opinion implementing the patch.

Thanks,
Balint



 On Mon, Jun 23, 2014 at 11:30 AM, Wireshark code review
 code-review-do-not-re...@wireshark.org wrote:

 URL:
 https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=9079e3ad1d32c594309a52ccef5936d11a93a55d
 Submitter: Anders Broman (a.broma...@gmail.com)
 Changed: branch: master
 Repository: wireshark

 Commits:

 9079e3a by AndersBroman (anders.bro...@ericsson.com):

 Cheat and try to fix the generated file manually.

 Change-Id: Iabf1821aa0ef676ac4d1d7f2983460b2e671a98a
 Reviewed-on: https://code.wireshark.org/review/2573
 Reviewed-by: Anders Broman a.broma...@gmail.com


 Actions performed:

 from  c9a5fbe   Optimize sip_is_known_sip_header()
 adds  9079e3a   Cheat and try to fix the generated file manually.


 Summary of changes:
  epan/dissectors/packet-sip-hdrs.c |   30 +-
  1 file changed, 25 insertions(+), 5 deletions(-)

 ___
 Sent via:Wireshark-commits mailing list
 wireshark-comm...@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-commits
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits

 mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe



 ___
 Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
 Archives:http://www.wireshark.org/lists/wireshark-dev
 Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] RTP Player

[Bálint Réczey]

2014-06-20 7:38 GMT-07:00 Jeff Morriss jeff.morriss...@gmail.com:
 On 06/18/14 21:07, Evan Huus wrote:

 We have at least 30 bugs to do with RTP and the analysis/audio player:
 https://bugs.wireshark.org/bugzilla/buglist.cgi?quicksearch=rtp

 Do we have a plan for the Qt equivalent of this UI? Is it worth doing,
 or should we hand it off to the OS's media player (gstreamer or similar)
 or...?


 My impression is that it is a very popular feature.  I would guess that a
 port or equivalent functionality would be needed before dropping the Gtk UI
 (unless we want people sticking with 1.12 longer than otherwise necessary).


 I would really like to WONTFIX a lot of these, unless somebody plans to
 spend any time fixing it...


 Personally I'd suggest leaving them there until the *are* fixed:
 probably/hopefully with a Qt port or alternative.
+1
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] RTP Player

[Bálint Réczey]

2014-06-18 18:07 GMT-07:00 Evan Huus eapa...@gmail.com:
 We have at least 30 bugs to do with RTP and the analysis/audio player:
 https://bugs.wireshark.org/bugzilla/buglist.cgi?quicksearch=rtp

 Do we have a plan for the Qt equivalent of this UI? Is it worth doing, or
 should we hand it off to the OS's media player (gstreamer or similar) or...?

 I would really like to WONTFIX a lot of these, unless somebody plans to
 spend any time fixing it...
I think we did a great job in visiting/updating and sometimes even
fixing many bugs in the las days, but we don't have a strong reason
for reaching zero with the bug backlog.
I like the concept that bugs are part of the documentation and having
them open does not really hurt anyone.
I think we are starting to cross the line where are closing bugs for
the sake of having them closed instead of using them as (valid)
reminders...

All the users reporting those 30 bugs were interested in having the
feature and we can't tell the number of users who did not open new
bugs because they saw the open ones and went back to their jobs
knowing that the problem they were facing will be fixed eventually.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Are tfshark/filetap ready for 1.12?

[Bálint Réczey]

Hi,

I'm wondering if we should ship tfshark and the filetap libraries in 1.12.
There is no man page or documentation for tfshark and they are both in
very early phase of development. I'm not sure how they are useful for
end users in their current form.

The questions formed in me while trying to provide meaningful
descriptions of them for the Debian packages. :-)

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Reminder: 1.12 branch tomorrow

[Bálint Réczey]

2014-06-05 13:29 GMT+07:00 Alexis La Goutte alexis.lagou...@gmail.com:
 On Tue, Jun 3, 2014 at 7:19 PM, Bálint Réczey bal...@balintreczey.hu wrote:
 Hi,

 2014-05-23 6:33 GMT+07:00 Gerald Combs ger...@wireshark.org:
 Reminder: I'm going to create the master-1.12 branch along with the
 other changes listed below tomorrow.


  Original Message 
 Subject: 1.12 branch + release schedule
 Date: Mon, 19 May 2014 14:46:42 -0700
 From: Gerald Combs ger...@wireshark.org
 Organization: Wireshark Foundation
 To: Developer support list for Wireshark wireshark-dev@wireshark.org

 Hi,

 I'd like to create the 1.12 branch this Friday (May 23) followed by
 1.12.0rc1 in late May or early June. I'm planning on the following:


 In master-1.12:

 - Set the major.minor versions to 1.12.
 - Choose sensible names for the GTK+ and Qt binaries in the NSIS
   installer, e.g. Wireshark and Wireshark 2 preview
 - Enable GTK+ and disable Qt by default in the NSIS installer.
 - Switch the 64-bit OS X package back to GTK+ while quietly weeping[1].
 - Drop support for Windows XP[2].

 I have uploaded 1.12.0 RC1 to Debian experimental using CMake as the
 build system and shipping the Qt GUI in wireshark-qt package with the
 binary qtshark renamed to wireshark-qt to help users in finding it
 more easily:
 http://packages.qa.debian.org/w/wireshark.html
 Nice !
I have filed a review for sync-ing our .deb generation with what
Debian has, mostly for switching to CMake:
https://code.wireshark.org/review/1986
I have tested it on Debian Wheezy.


Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Reminder: 1.12 branch tomorrow

[Bálint Réczey]

Hi,

2014-05-23 6:33 GMT+07:00 Gerald Combs ger...@wireshark.org:
 Reminder: I'm going to create the master-1.12 branch along with the
 other changes listed below tomorrow.


  Original Message 
 Subject: 1.12 branch + release schedule
 Date: Mon, 19 May 2014 14:46:42 -0700
 From: Gerald Combs ger...@wireshark.org
 Organization: Wireshark Foundation
 To: Developer support list for Wireshark wireshark-dev@wireshark.org

 Hi,

 I'd like to create the 1.12 branch this Friday (May 23) followed by
 1.12.0rc1 in late May or early June. I'm planning on the following:


 In master-1.12:

 - Set the major.minor versions to 1.12.
 - Choose sensible names for the GTK+ and Qt binaries in the NSIS
   installer, e.g. Wireshark and Wireshark 2 preview
 - Enable GTK+ and disable Qt by default in the NSIS installer.
 - Switch the 64-bit OS X package back to GTK+ while quietly weeping[1].
 - Drop support for Windows XP[2].

I have uploaded 1.12.0 RC1 to Debian experimental using CMake as the
build system and shipping the Qt GUI in wireshark-qt package with the
binary qtshark renamed to wireshark-qt to help users in finding it
more easily:
http://packages.qa.debian.org/w/wireshark.html

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Is it possible to update the version of gcrypt?

[Bálint Réczey]

Hi,

2014-04-01 9:58 GMT+07:00 Gerald Combs ger...@wireshark.org:
 On 3/31/14, 6:35 PM, Pascal Quantin wrote:
 2014-03-31 20:02 GMT+02:00 Gerald Combs ger...@wireshark.org
 mailto:ger...@wireshark.org:

 On 3/30/14 10:00 AM, Pascal Quantin wrote:
  2014-01-08 0:25 GMT+01:00 Pascal Quantin pascal.quan...@gmail.com
 mailto:pascal.quan...@gmail.com
  mailto:pascal.quan...@gmail.com mailto:pascal.quan...@gmail.com:

  Gerald, according to the README.Wireshark file found in
  gnutls-2.12.18-1.2-win32ws archive, you manually modified the
  OpenSUSE packages:
- Definition files were created using pexports.
- Import libraries were created using the MSVC++ lib utility
  using the make-lib.sh script.
  I do not know where to find those utilities neither how to use
 them.

 pexports is its own package in OpenSUSE, although it looks like
 gendef (or even libtool itself) might be the preferred way to generate
 .def files nowadays.

 make-lib.sh is in the bin directory in
 gnutls-2.12.18-1.2-win32ws.zip. It's just a series of lib
 commands, e.g.

 lib /machine:x86 /def:libgcrypt-11.def /name:libgcrypt-11.dll \
   /out:libgcrypt-11.lib


  Maybe those missing steps on my side can explain my issue.
 Would you
  be OK if we to try to upgrade those libraries? If yes, could
 you help?
 
  2 small things I noted:
  - libgcrypt-11.dll/lib is now renamed libgcrypt-20.dll/lib. It
  impacts config.nmake, Makefile.nmake,
  cmake\modules\FindGCRYPT.cmake, packaging\nsis\wireshark.nsi and
  ui\qt\QtShark.pro
  - the openSUSE libraries require an extra libgcc_s_sjlj-1.dll file
  found in mingw32-libgcc-4.8.2-1.2.noarch.rpm archive (my own
  compiled libraries did not need it but I failed to compile a win64
  variant so far).

 It looks like that's an exception handling library which can be linked
 statically:

 
 http://stackoverflow.com/questions/12921911/mingw-libgcc-s-sjlj-1-dll-is-missing

 
 
  Hi all,
 
  I restarted playing with the libraries provided by OpenSUSE this
 weekend
  and was able to get libgcrypt 1.6.0 working on my Windows machine.
  The remaining problem is that we should either recompile GnuTLS
 2.12.18
  with this newer libgcrypt (Im' not willing to do so), or upgrade
 GnuTLS
  to the version 3.1.22 provided by OpenSUSE.
  We deactivated the use of GnuTLS 3.X in the past due to their move to
  GPL3.0. But according to their website and the header files, the core
  library is still LGPL 2.1+. Would it make it usable for us?

 GnuTLS switched to LGPLv3+ in version 3.0, then back to LGPLv2.1+ in
 version 3.1.10. We need switch to a newer 3.x release at some point
 since the 2.12 branch is no longer maintained as far as I know. However,
 we need to be careful with the version of GMP that we ship since it
 switched to LGPLv3+:

 https://gmplib.org/list-archives/gmp-devel/2013-August/003357.html


 OK, here is where I stand.
 I have a patch allowing to build win32 and win64 (presumably, I do not
 have access to my win64 machine for a few days) Wireshark against GnuTLS
 3.1.22 and Grrypt 1.6.0 (thanks to the pre built packages provided by
 OpenSUSE).
 The newer GnuTLS 3.1.22 package creates new dependencies on the
 following packages: libgmp-5.0.5, libnettle-2.7-3, libhogweed-2.7-3,
 libp11-kit0-0.20.1 and libffi-3.0.13.
 Nettle is LGPL, p11-kit and ffi license does not seem problematic, and
 GMP 5.0.5, as you stated, is LGPLv3+ (only release 4.2.1 seems usable).
 So this is definitely a blocker.
 There is also an issue with the libp11-kit0-0.20.1 library provided by
 OpenSUSE folks. It uses the function strerror_s from MSVCRT.dll, but
 this symbol is not exported by the Windows XP MSVCRT (it is running fine
 on Windows 7). I was about to try to recompile the p11-kit library
 myself to avoid this dependency but the GMP licensing issue is
 depressing (I did not check yet how difficult it was to recompile the
 4.2.1 version and hope that it would work with the GnuTLS pre compiled
 library).

 It looks like GMP has been relicensed to GPLv2+ / LGPLv3+ as of 6.0.0
 (released a few days ago). Hopefully the OBS packages will be updated soon.
I have just switched the wireshark package in Debian to use GnuTLS 3
with the appropriate GMP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747578

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark LTS branches

[Bálint Réczey]

Hi,

2014-04-18 21:51 GMT+07:00 Jeff Morriss jeff.morriss...@gmail.com:
 On 04/17/14 23:11, Guy Harris wrote:


 On Apr 17, 2014, at 3:58 PM, Bálint Réczey bal...@balintreczey.hu wrote:

 Well, last time I brought this up the project decision was to allow
 minor improvements, too:
 http://comments.gmane.org/gmane.network.wireshark.devel/15323

 The best solution for me as a maintainer at Debian would be limiting
 the changes to security fixes conforming to the policy:
 https://www.debian.org/security/faq#policy , but as a second-best
 option I could live with the special LTS branches.


 The best solution for many end-users would probably be *not* to limit the
 changes to security fixes - if we have a fix for a mis-dissection, they'd
 probably want that, for example.


 I agree.  I push the stable release micro versions to my users because it's
 often important to have bug fixes too.

 Fedora appears to be picking up the micro-releases as-is (Fedora 18 actually
 even upgraded from 1.8.3 to 1.10.2; hopefully this means they've come to
 think of Wireshark as a desktop app like Firefox which must be reasonably
 up-to-date in order to be useful).
Debian does that with Firefox, too, not because it is a desktop app,
but AFAIK because upstream refuses providing separated security fixes
and mining them from micro-releases is prohibitively time consuming
for the Firefox (Iceweasel) package maintainers.
Luckily being a Wireshark Developer in addition to a DD and thanks to
Wireshark's more maintainer-friendly release policy I was able to
extract security fixes from point releases thus we (Debian) did not
have to make an exception for Wireshark.
Having the aforementioned LTS branches would help me in ensuring
better quality of back-ported patches and would help other
distributions' wireshark maintainers to pick the same patches more
easily.
It is also worth mentioning that Debian stable has latest Wireshark
(1.10.7) packaged too, through Debian's official wheezy-backports thus
users of stable can choose between the slower-moving 1.8.2 + security
patches and the latest upstream's stable version.



 Given that, having separate security fixes only branches, for packagers
 and users who *only* want security fixes, and support branches, for
 packagers and users who also want those bug fixes that we deem appropriate
 for the support branches, is probably the right answer.


 ... And on the other hand we have RHEL/CentOS which seem to be manually
 applying patches: 6.0 came with Wireshark 1.8.10-4 (the -4 being their
 nano-version) and the latest update appears to be 1.8.10-7.

 The problem, I think, with having security fixes only branches is that
 different distributions pick different starting points--probably based on
 when they ship.  Balint/Debian, for example, wants a branch off of 1.8.2 but
 it appears RHEL/CentOS would like one off of 1.8.10. Obviously this doesn't
 scale well [for us] so presumably we'd only do master-lts-1.8.0 [at least
 for future versions]?
Usually the most obvious bugs are found and fixed in the early
versions of each maintenance branch thus I would not pick .0, but the
first version when any major distribution or party signals the need
for starting an LTS branch.
(I'm a bit surprised that no one showed up from RH or SuSe in this thread.)


 Another aspect is I'd be willing to bet that RHEL doesn't apply just
 security fixes but also bug fixes that their (paying) customers have run
 into--so they might not use our lts branch anyway.
Even though they probably won't use our LTS branches it would help
them in picking security fixes.

I have prepared the branches in form of patches ready for being 'git
am' -ed here:
http://cs.bme.hu/~rbalint/lts-1.2.11.tar.gz
http://cs.bme.hu/~rbalint/lts-1.8.2.tar.gz

They were forked off from 1.2.11 and 1.8.2 respectively and they
contain the non-Debian-specific changes used in the Debian security
updates.
I think the new branches could be called simply lts-1.2.11 and
lts-1.8.2, but I would be fine with master-lts-x.y.z or any other
scheme.

I think there is no opposition formed against the proposed LTS
branches so if Gerald agrees he could name and start the branches and
I would submit the proposed content through Gerrit or he could import
and push the content directly.

Is there other concerns, comments?

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-core] Hash Tables and Algorithmic Complexity Attacks

[Bálint Réczey]

[Bringing the discussion to -dev with Evan's permission]

2014-04-22 10:15 GMT+02:00 Anders Broman anders.bro...@ericsson.com:


 -Original Message-
 From: wireshark-core-boun...@wireshark.org 
 [mailto:wireshark-core-boun...@wireshark.org] On Behalf Of Evan Huus
 Sent: den 22 april 2014 05:36
 To: Wireshark core developers
 Subject: Re: [Wireshark-core] Hash Tables and Algorithmic Complexity Attacks

 On Mon, Apr 21, 2014 at 6:28 PM, Balint Reczey rbal...@gmail.com wrote:

 On Apr 22, 2014 12:11 AM, Evan Huus eapa...@gmail.com wrote:

 On Mon, Apr 21, 2014 at 3:59 PM, Bálint Réczey bal...@balintreczey.hu 
 wrote:
  Hi Evan,
 
  2014-04-21 18:21 GMT+02:00 Evan Huus eapa...@gmail.com:
  (sending to -core because of potential security implications)
 
  I was recently investigating implementing a wmem-based hash table,
  since many of the current users of the wmem-tree do not actually
  need the predecessor-lookup feature which is the only advantage it
  provides over a hash table (whereas a hash table is otherwise much 
  faster).
 
  I ended up wandering down the rabbit-hole of hash collisions,
  algorithmic complexity attacks, and universal hashing ([1], [2],
  [3] and more).
 
  Then I read the Glib hash table documentation: [4]. A quick grep
  through the Wireshark source reveals numerous locations where we
  use packet data in hash tables with insecure hash functions. As
  such, I believe that Wireshark is vulnerable to a whole class of
  denial-of-service attacks in this area.
 
  Has this come up before? Am I overlooking something clever we're doing?
  It is true that Wireshark is vulnerable to hash collision attacks,
  and I think it did not come up before because we had enough
  vulnerabilities of other simpler classes. ;-)

 Makes sense :)

  I think we could create wrappers to provide random seed to standard
  glib hash functions which is the standard way of handling such
  vulnerabilities.

 Unfortunately (based on my reading) that will not be sufficient.
 There are two vectors for an attack via collisions: the mapping from
 key to guint, and the mapping from guint to bucket index. The first
 (key-guint) is user-settable so we can provide a random seed. The
 second (guint-bucket) is not user-controllable. From the glib
 documentation:

 The modulus is taken with the hash table size (a prime number) to
 find the 'bucket' to place each key into.
 and then a few paragraphs down
 Even cryptographic hashes are very easy to find collisions for when
 the remainder is taken modulo a somewhat predictable prime number.

 So basically, it doesn't matter how strong we make the initial
 mapping because the secondary bucket mapping is predictable anyways.
 Fortunately there are easy and efficient ways to make the secondary
 mapping unpredictable (it's actually simpler than the initial
 mapping) so I guess that a good secure wmem map implementation is
 actually fairly important to have.
 Luckily ghashtable resizes itself increasing the number of buckets when the 
 collision rate is high, thus this attack can't be performed effectively.
 The described problem is valid only for hash tables with fixed bucket count.

 Regarding the wmem hash tables I think C wrapping C++ STL hash tables with 
 wmem based custom allocators would do the job.

Unfortunately this doesn't work; the free-all operation which wmem provides 
doesn't play nice with C++ destructors (besides which we are still pure-C for 
libwireshark for the time being).
We lost being C only with the Qt UI. :-)
It can be implemented several ways which work, one is registering each
hash table to the proper wmem pool and calling their destructor when
freeing the pool - this way we don't have to play with a custom
allocator.
Other technique would be not calling destructors, just freeing all the
allocated connected objects. This is not nice, but would work as well
IMO, since we would not hold refs to the free()-d objects.


I have whipped up a very basic wmem-map implementation at [1]. It uses 
universal multiply-shift hashing [2] for bucket placement, and provides a 
wmem_secure_hash function for replacing g_str_hash and friends, based on 
work done by the Perl community [3] in hardening their hash tables. To the 
best of my knowledge the resulting hash map is secure against complexity 
attacks.

It still needs cleanup (comments, tests, etc). I would also like to replace 
one tree somewhere and run benchmarks to make sure it's actually faster. 
Suggestions and concerns are welcome.
It would be nice to see how it compares to other implementations:
http://incise.org/hash-table-benchmarks.html

I prefer using existing building building blocks instead of inventing our own.

Cheers,
Balint


[1] https://code.wireshark.org/review/1272
[2] 
https://en.wikipedia.org/wiki/Universal_hashing#Avoiding_modular_arithmetic
[3] http://blog.booking.com/hardening-perls-hash-function.html


 Would it be good to have initial hastable size in the API? So a table could

Re: [Wireshark-dev] Wireshark LTS branches

[Bálint Réczey]

Hi Gerald,

2014-04-17 1:59 GMT+02:00 Gerald Combs ger...@wireshark.org:
 On 4/16/14 3:42 AM, Bálint Réczey wrote:
 Hi,

 Many of you probably know about the Wireshark package [1] in Debian
 which I started maintaining a few years ago. Like every other package
 in Debian, the version of Wireshark included in the major distribution
 release is getting security and stability updates through the lifetime
 [2] of the major distribution release which is typically 3 years, but
 it is still shorter than the lifetime of an Ubuntu LTS (5 years) or
 Red Hat [3] (10 years).

 Wireshark, the Project, makes a major release every year and according
 our current policy we support [4] the current and previous release
 which makes Wireshark releases lifetime 2 years.

 Wireshark makes point releases after each major release fixing bugs
 adding minor features and improvements, but only the security and some
 stability related fixes get included in updates to the Debian package.
 Since the Debian packages have longer lifetime than Wireshark release
 I back-port security related fixes to older releases than the project
 which means that I already maintain two Wireshark branches with
 security fixes only in the form of patch sets [5]. Other distribution
 maintainers do the same.

 Since we moved to Git maintaining the branches became easier and I
 would like to as the project to allow me to maintain the two existing
 branches in the projects repository. Going forward I would like to
 open one similar branch for at least every Debian major release and
 maintain at least through the major release's lifetime.

 I think it would not create any significant additional work for the
 community but it would provide many advantages.

 1. We could provide an upgrade path for people focused only on
 security but not on other improvements keeping the existing release
 plan.
 2. Distribution maintainers could eliminate the duplicate work by
 collaborating in the LTS branches.
 3. Back-ported fixes could get better testing using the existing
 buildbot infrastructure.
 4. Back-ported fixes could be reviewed by more people.

 One additional note regarding Debian, we (at Debian) are thinking
 about extending the lifespan of each release to 5 years [7] and this
 would extend my commitment to maintaining the Wireshark LTS branches
 naturally.

 Would the Project be open for the proposed branches?

 Overall it sounds fine to me. How many branches would be created and how
 would they be named?
I would like to create two branches forking off from 1.2.11 1.8.2
because those are the base versions for Debian oldstable and stable.
If others are interested, we could find an LTS forking point for every
major branch, but those are which I maintain already.

The next could fork off from 1.12.x based on the freeze date for next
stable, which is November 5th. If other distributions are interested
we could find a forking point which would fit their release schedule
as well.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark LTS branches

[Bálint Réczey]

2014-04-17 23:21 GMT+02:00 Evan Huus eapa...@gmail.com:
 On Thu, Apr 17, 2014 at 4:23 AM, Anders Broman
 anders.bro...@ericsson.com wrote:


 -Original Message-
 From: wireshark-dev-boun...@wireshark.org 
 [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Bálint Réczey
 Sent: den 17 april 2014 09:59
 To: Gerald Combs
 Cc: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] Wireshark LTS branches

 Hi Gerald,

 2014-04-17 1:59 GMT+02:00 Gerald Combs ger...@wireshark.org:
 On 4/16/14 3:42 AM, Bálint Réczey wrote:
 Hi,

 Many of you probably know about the Wireshark package [1] in Debian
 which I started maintaining a few years ago. Like every other package
 in Debian, the version of Wireshark included in the major
 distribution release is getting security and stability updates
 through the lifetime [2] of the major distribution release which is
 typically 3 years, but it is still shorter than the lifetime of an
 Ubuntu LTS (5 years) or Red Hat [3] (10 years).

 Wireshark, the Project, makes a major release every year and
 according our current policy we support [4] the current and previous
 release which makes Wireshark releases lifetime 2 years.

 Wireshark makes point releases after each major release fixing bugs
 adding minor features and improvements, but only the security and
 some stability related fixes get included in updates to the Debian package.
 Since the Debian packages have longer lifetime than Wireshark release
 I back-port security related fixes to older releases than the project
 which means that I already maintain two Wireshark branches with
 security fixes only in the form of patch sets [5]. Other distribution
 maintainers do the same.

 Since we moved to Git maintaining the branches became easier and I
 would like to as the project to allow me to maintain the two existing
 branches in the projects repository. Going forward I would like to
 open one similar branch for at least every Debian major release and
 maintain at least through the major release's lifetime.

 I think it would not create any significant additional work for the
 community but it would provide many advantages.

 1. We could provide an upgrade path for people focused only on
 security but not on other improvements keeping the existing release
 plan.
 2. Distribution maintainers could eliminate the duplicate work by
 collaborating in the LTS branches.
 3. Back-ported fixes could get better testing using the existing
 buildbot infrastructure.
 4. Back-ported fixes could be reviewed by more people.

 One additional note regarding Debian, we (at Debian) are thinking
 about extending the lifespan of each release to 5 years [7] and this
 would extend my commitment to maintaining the Wireshark LTS branches
 naturally.

 Would the Project be open for the proposed branches?

 Overall it sounds fine to me. How many branches would be created and
 how would they be named?
 I would like to create two branches forking off from 1.2.11 1.8.2 because 
 those are the base versions for Debian oldstable and stable.
 If others are interested, we could find an LTS forking point for every major 
 branch, but those are which I maintain already.

 The next could fork off from 1.12.x based on the freeze date for next 
 stable, which is November 5th. If other distributions are interested we 
 could find a forking point which would fit their release schedule as well.
I forgot to answer the question regarding the naming,
master-lts-1.2.11 and master-lts-1.8.2 would be close to the current
scheme, I think.


 Hmm this seems backwards to me, if the distributions don't take the point 
 releases we make, there is something wrong with our point releases or we 
 shouldn't be making them in
 The first place if no one is using them. Seems like a lot of work for 
 nothing to me.

 This was also my original reaction. We do a fair amount of work (or at
 least Gerald does quite a lot of work), maintaining stable and
 old-stable Wireshark branches already. It seems like it would be
 easier for everybody if we tweaked our stable-backport policy so that
 Debian and whoever else could just grab new stable versions from us
 directly.

 I can't speak for Debian, but Ubuntu has a specific policy for this
 sort of thing:
 https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions

 Should we change our backport policy to fit the distributions need or are 
 they to different to have a fits all procedure. Perhaps the distribution 
 should point out which backports to do?

Well, last time I brought this up the project decision was to allow
minor improvements, too:
http://comments.gmane.org/gmane.network.wireshark.devel/15323

The best solution for me as a maintainer at Debian would be limiting
the changes to security fixes conforming to the policy:
https://www.debian.org/security/faq#policy , but as a second-best
option I could live with the special LTS branches.

Ubuntu usually syncs security updates without changes from Debian

[Wireshark-dev] Wireshark LTS branches

[Bálint Réczey]

Hi,

Many of you probably know about the Wireshark package [1] in Debian
which I started maintaining a few years ago. Like every other package
in Debian, the version of Wireshark included in the major distribution
release is getting security and stability updates through the lifetime
[2] of the major distribution release which is typically 3 years, but
it is still shorter than the lifetime of an Ubuntu LTS (5 years) or
Red Hat [3] (10 years).

Wireshark, the Project, makes a major release every year and according
our current policy we support [4] the current and previous release
which makes Wireshark releases lifetime 2 years.

Wireshark makes point releases after each major release fixing bugs
adding minor features and improvements, but only the security and some
stability related fixes get included in updates to the Debian package.
Since the Debian packages have longer lifetime than Wireshark release
I back-port security related fixes to older releases than the project
which means that I already maintain two Wireshark branches with
security fixes only in the form of patch sets [5]. Other distribution
maintainers do the same.

Since we moved to Git maintaining the branches became easier and I
would like to as the project to allow me to maintain the two existing
branches in the projects repository. Going forward I would like to
open one similar branch for at least every Debian major release and
maintain at least through the major release's lifetime.

I think it would not create any significant additional work for the
community but it would provide many advantages.

1. We could provide an upgrade path for people focused only on
security but not on other improvements keeping the existing release
plan.
2. Distribution maintainers could eliminate the duplicate work by
collaborating in the LTS branches.
3. Back-ported fixes could get better testing using the existing
buildbot infrastructure.
4. Back-ported fixes could be reviewed by more people.

One additional note regarding Debian, we (at Debian) are thinking
about extending the lifespan of each release to 5 years [7] and this
would extend my commitment to maintaining the Wireshark LTS branches
naturally.

Would the Project be open for the proposed branches?

Cheers,
Balint

PS: The Debian-specific parts would not be be included in the
Wireshark LTS branches.

[1] http://packages.qa.debian.org/w/wireshark.html
[2] https://wiki.debian.org/DebianReleases
[3] https://access.redhat.com/site/support/policy/updates/errata/
[4] http://wiki.wireshark.org/Development/Roadmap
[5] http://patch-tracker.debian.org/package/wireshark/1.2.11-6+squeeze13
[6] http://patch-tracker.debian.org/package/wireshark/1.8.2-5wheezy9
[7] http://bits.debian.org/2014/03/working-on-squeeze-lts.html
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe