Hi,
On Wed, 27 Jun 2018 at 19:50, wrote:
> I don't think there's any guarantee of not crashing unless you can
> guarantee the data is not corrupted. For example, it contains lengths of
> patterns, and if these are overwritten, it might read past the end of
> the data. There are sanity checks on
On Wed, 2018 Jun 27 18:23+0100, p...@hermes.cam.ac.uk wrote:
>
> OK, I have done this in several places in several man pages that refer
> to serialization. The main one did specify the restrictions, but I
> hope the additional wording will make it crystal clear what the
> facility provides. (And
On Mon, 25 Jun 2018, Giuseppe D'Angelo via Pcre-dev wrote:
> Not as a general way, but it's been a requested feature for
> QRegularExpression to be able to save/restore the bytecode. While I
> can tell the users to never restore from untrusted data, my question
> was about data saved from PCRE
On Mon, 25 Jun 2018, Daniel Richard G. wrote:
> While I wouldn't go so far as to say the API names should change, I do
> think it would be good to have a blurb in the pcre2serialize doc along
> the lines of
OK, I have done this in several places in several man pages that refer
to
On Mon, 25 Jun 2018, Daniel Richard G. wrote:
> While I wouldn't go so far as to say the API names should change, I do
> think it would be good to have a blurb in the pcre2serialize doc along
> the lines of
Yes, agreed. I will do something like that.
Philip
--
Philip Hazel
--
## List
On Mon, 2018 Jun 25 20:14+0200, Zoltán Herczeg wrote:
> > I can understand that. But I would point out that PCRE2's current
> > notion of serialization is quite limited compared to what that word
> > usually implies (cf. Java, .NET object serialization), so this is
> > not likely to be the only
On Mon, 25 Jun 2018 at 16:28, wrote:
>
> On Sun, 24 Jun 2018, Giuseppe D'Angelo via Pcre-dev wrote:
>
> > Orthogonal question: is that the amount of information sufficient to
> > protect against decoding of trusted data, but on the wrong OS / PCRE
> > installation / etc.?
>
> As long as it's the
> I can understand that. But I would point out that PCRE2's current notion
> of serialization is quite limited compared to what that word usually
> implies (cf. Java, .NET object serialization), so this is not likely to
> be the only time that an application developer finds the functionality
>
On Sun, 24 Jun 2018, Giuseppe D'Angelo via Pcre-dev wrote:
> Orthogonal question: is that the amount of information sufficient to
> protect against decoding of trusted data, but on the wrong OS / PCRE
> installation / etc.?
As long as it's the same endianness and the same PCRE2 release, it
PhilIt might be a good idea to add some id in the serialized object that stores
the PCRE2 version and than, any subsequent version would be able to decide
whether it is compatible or not.
Ze'ev Atlas
On Friday, June 22, 2018, 4:12:27 PM EDT, Daniel Richard G.
wrote:
On Fri, 2018 Jun
On Fri, 2018 Jun 22 15:35+0100, p...@hermes.cam.ac.uk wrote:
> On Fri, 22 Jun 2018, Zoltán Herczeg wrote:
>
> > well, this is much more ambitious than what we have now (or what we
> > have ever planned :) ). Anyway doing this is definitely possible,
> > but far from beaing a trivial amount of
On Fri, 22 Jun 2018, Zoltán Herczeg wrote:
> well, this is much more ambitious than what we have now (or what we
> have ever planned :) ). Anyway doing this is definitely possible, but
> far from beaing a trivial amount of work. Finding resources to do it
> is probably the challenge here.
Hi,
> In my use case, however, the application has binary data files
> [containing serialized regexes] under /usr/share/foo/, and no provision
> is available to cache under /var/, nor any other writable disk location.
> PCRE2 can be updated at any time due to security vulnerabilities, but
> the
Hi Zoltán, it's been a while!
On Fri, 2018 Jun 22 05:55+0200, Zoltán Herczeg wrote:
> Hi,
>
> to tell the truth, when the serialization was created the use case we
> were discussing was different from the use case below.
>
> I consider serialized forms inherently unsecure. I would never
>
Eredeti levél
Feladó: p...@hermes.cam.ac.uk (Link -> mailto:p...@hermes.cam.ac.uk)
Dátum: 2018 június 21 10:29:06
Tárgy: Re: [pcre-dev] Serialization format versioning
Címzett: Daniel Richard G. < sk...@iskunk.org (Link -> mailto:sk...@iskunk.org)
>
On Wed, 20 Jun 2018, Dani
Hi Philip,
On Thu, 2018 Jun 21 09:27+0100, p...@hermes.cam.ac.uk wrote:
> On Wed, 20 Jun 2018, Daniel Richard G. wrote:
>
> > Is it not feasible for the serialized form to be forward-compatible
> > with later versions of PCRE2?
>
> Zoltán may correct me on this, but basically we felt that this
On Wed, 20 Jun 2018, Daniel Richard G. wrote:
> Is it not feasible for the serialized form to be forward-compatible with
> later versions of PCRE2?
Zoltán may correct me on this, but basically we felt that this would be
too much of a constraint on future development. Changes to what is
compiled
Hi everyone,
I have been working on an application that uses PCRE2, along with the
serialization API. The serialization API is a major gain over PCRE1,
especially as this application makes use of fairly large regexes that
take a non-trivial amount of time to compile.
However, I am seeing that
18 matches
Mail list logo
