search

Exiv2 / exiv2

Image metadata library and tools
http://www.exiv2.org/
Other
887 stars 279 forks source link

Exiv2 RoadMap #1018

Open D4N opened 4 years ago

D4N commented 4 years ago

Recently our main contributor Robin (@clanmills) decided to retire from the project effective immediately. We don't have to fool ourselves: Robin has been the driving force behind this project for roughly a decade now and invested a truly insane amount of time and effort into it. No one of the currently active contributors has either the time or the expertise to match him. This leaves us in a tough spot: how can we keep this project alive and going?

Current state

Short term steps

I propose the following to steps in the short term (until the end of 2019):

Long term steps

I see the following options:

What can we do to improve our processes?

The past showed that our current contribution process became rather complicated, which already drove away contributors. This is bad.

How can we improve for one time contributors?

How can we improve the process for long term contributors?

How can we attract more people to contribute?

Any further ideas/comments/suggestions?

D4N commented 4 years ago

cc @tbeu @piponazo @sridharb1 @tester0077 @kevinbackhouse @derselbst @nehaljwani @fgeek @cryptomilk

cgilles commented 4 years ago

Hi all,

I'm always listening Exiv2 conversation, even if i'm not very active in the project.

As digiKam use Exiv2 API to handle all metadata excepted video, considerate me as present for some task. one where i'm interested is to support new image format. actually i finalize the HEIC/HEIF support in digiKam. I know that an entry exist to support this format in Exiv2, so i will be ready to check code and test new implementation for a quick move in production.

https://i.imgur.com/JmEgGNS.png https://i.imgur.com/MlNxPLa.png

I plan also to integrate Webp, Jpegxr, FLIF, support as native loader in digiKam in the future. So All plan to support these file format in Exiv2 are in my mind.

As i practice cmake since 8 years actively in digiKam and in my office, i can help for CMake problems in Exiv2. Just ask me if necessary.

In digiKam, i implemented a lots of unit tests to check the large Qt / Exiv2 interface, with a huge collection of images. I already discovered plenty of non re-entrancy in Exiv2 API and i consolidate digiKam code with several lock, as we use multi-threading and multi-core everywhere. In digiKam, Exiv2 API is only located in the core Qt interface. So the code in use is limited and not dispatched everywhere. Rememeber that digiKam code is more than 1.5 M of C++ code lines.

I'm also aware about the MinGW port, as we cross compile ALL the digiKam code + all dependencies for Windows under Linux using MXE. I'm in love with cross compiling, so if something do not work here, i'm ready to report a fix quickly.

digiKam has a large users base, and we publish weekly a new test version for Linux, Windows, and MacOS. If something is broken or do not work in Exiv2, we are able to report the dysfunction quickly.

Voilà, I'm here to help you if necessary if time permit.

Best

Gilles Caulier

fgeek commented 4 years ago

Thank you Robin Mills for all your efforts towards better open-source software. It was a pleasure to cooperate with you :+1:

phako commented 4 years ago

Mainly some random thoughts there, sorry

tester0077 commented 4 years ago

First of all, a very big "Thank you" to Robin and his work on behalf of Exiv2. I have always found him very responsive and helpful.

And the same goes for all of the other maintainers, though it seems there are only two others. :(

Having worked a good deal with other people's open source code with multiple dependencies on other similar open source libraries & trying to adapt them to my needs and environment, I understand a good many of the issues they have been facing.

As for the future of Eviv2, I am not sure I can offer much help, other than a few comments.

My own use of Exiv2 is simply for a couple of pet projects of mine. One, started several years ago to try to analyze and, hopefully, edit image metadata for my family tree project and a second one, which I forked form an existing and apparently abandoned or stalled project, much for a similar  reason: collecting all of my images and documents for the family tree project This latter one had already been designed with Exiv2 as a basic and necessary component, but had not been using the latest version, nor was it using many of Exiv2's features as probably intended. The fact that it was using the Exiv2 libraries, was part of my decision to use it as a starting point.

There is another, somewhat remotely connected, project, also part of my family tree project, namely the pyexiv?? code used as part of the Gramps project.

If exiv2 were to 'stall', for my own projects, I would have to carry on as I have for others: grab the latest code and then work with it on my own and 'beat it into shape' as best I could with my needs, background, time and environment.

Only recently have I started to use git, after a relatively long stable period of using SVN, though neither of these to anywhere near their full potential for serious development. Hence, using git and particularly Github and its 'cousins' by myself, requires a lot of effort and time because of their steep learning curve  - both of which are always in short supply.

As for keeping exiv2 going, I had been wondering to whom the project is or would be important enough to either sponsor the project or take on the job that Robin was doing. The current maintainers might be in a much better position to assess that than myself

There definitely seems to be a move towards cloud, web or handheld device based applications, though I doubt that desktops will go away completely.

There is no question that another stumbling block, at least for myself, was the fact that the basic roots of both Exiv2 itself and several of the libraries it depends on, are in the Linux tradition with a whole set of different compilers and debugging environments. Porting all of this to the Windows OS involves a tremendous amount of extra software and effort. Not to mention the somewhat erratic update and maintenance cycles and their port to Windows for the libraries Exiv2 depends on.

On this issue, I must commend the Exiv2 team on their work to make the porting to Windows a whole lot more convenient with the conan and Cmake utilities. Still, even using those involves considerable effort and time on all sides. As a mostly Windows user, and without wanting to get into any flame wars, I very much appreciate that work by the team.

Licensing is another issue, though one which I, as a single developer with no plans to commercialize my applications, am neither qualified not interested in commenting on. Still for some people this will be THE issue and for many it will be a show stopper.

Thank you all.

Arnold

derselbst commented 4 years ago

Hi,

I am mainly a user of exiv2 (coming from gwenview) and pretty new to the team; Robin invited me recently. I'm familiar with C++, Cmake, CI. However, I'm also part of two other organizations here at GitHub, which require most of my free time. But I'll try my best to help out where I can, just ping me.

Regarding how to attract new contributors, I would like to mention that the number of contributors is actually growing. So things don't look too bad to me. Simplifying the review process sounds good to me, @D4N has raised some good ideas. A rewrite IMO would be counterproductive for this project.

phako commented 4 years ago

Btw, I need to release a new version of gexiv2 soonish. The document mirror on exiv2.dyndns.org is gone, I assume?

clanmills commented 4 years ago

exiv2.dyndns.org is gone. The release is on https://exiv2.org and the pre-release on https://pre-release.exiv2.org

A couple of obvious points about v0.27.3 (and later v0.27 dots) 1) You can publish source releases on GitHub without updating exiv2.org 2) If you publish releases on GitHub, I'm willing to update exiv2.org and build the binaries with Jenkins on the MacMini, if (and only if) the web and release code is stored on SVN. I've retired because of frustration with review/git/github.

I wish I could make the fuzzing police disappear or get them to participate in fixing security issues. They appear to have more resources than Team Exiv2. I believe Kevin is the only "fuzzer" who both reported and fixed CVEs.

phako commented 4 years ago

I ased regarding exvi2.dyndns.org because I received a patch to point all the docs to there. Which I will probably revert now.

Regarding the fuzzing: Unfortunately, fuzzing is quite use- and helpful. But, looking at eg. #1019 that ticket is basically useless.

clanmills commented 4 years ago

Jens: I seem to recall our conversation about dyndns.org in Exiv2 v0.27-RC days (about one year ago). Since then, thanks to @nehaljwani, we moved exiv2.org to a new AWS and have the pre-release web-site.

clanmills commented 4 years ago

I agree with you that fuzzing is useful. However the behaviour of the fuzzing police is very unhelpful and demotivating. That bug report today is a good example. I wouldn't be surprised if it's already fixed in v0.27.2 and is actually a waste of time.

piponazo commented 4 years ago

Hi all,

Thanks @D4N for the effort of creating this issue and giving details about the current state of the project and proposing some short/long terms actions to try to improve the situation. I find useful to have this open discussion in a github thread instead of having it in a chat.

Please find my feedback about each of the proposed steps:

Short term steps

Move the project into (hard) maintenance mode: i.e. no new features, just bugfixes.

I guess that here you are referring here about the support we can give to the project given our busy lives. I do not see myself contributing in new features during the next months, due to my personal situation, and I agree that if I find time to contribute to the project, I will do it fixing reported bugs in 0.27-maintenance.

Nonetheless, I would be more than happy to see people contributing new features to master and I will try to also dedicate time to review those PRs and guide contributors as much as possible.

Ensure that we can produce a 0.27.3 release by the end of 2019: create releases on our current CI without Jenkins. A prerequisite for that is that we can build exiv2 in a reproducible fashion (which is possible, openSUSE is already doing that with one patch).

I think it should be possible to generate the binary artifacts for 0.27.3 from travisCI and Appveyor. I could dedicate some to this topic in the next days/weeks. I remember that long ago we discussed about some security issue in travisCI regarding the deployment of binary artifacts and that's we discarded that option. Opinions about this ?

Move the exiv2 webpage to github or gitlab pages.

I like this idea. I think it is good to centralise as much as possible all the content/discussions about Exiv2 to a single place.

Migrate all existing svn repositories that are still out there to git under the Exiv2 org

I am not sure to what are you referring to here. Would you mind to develop a bit more this?

Long term steps

Drastically reduce the scope of Exiv2 to match only what our API consumers require

I think this is matching we some of the previous actions we have taken on master: i.e, to drop stuff not related with Image Metadata. Of course, any suggestions to keep improving the API would be welcomed.

We find new contributors. Imho unfortunately rather unlikely, as the past showed. We can try to raise awareness about exiv2, but unfortunately I don't really know how to make this project appealing to new contributors.

Not sure either about how to find new contributors. Exiv2 has been for me the first open source project in which I participate regularly. Somehow, after working on it for several months I felt responsible of addressing bugs and improving some specific areas ... I guess that newcomers would be interesting in addressing more interesting topics, such as adding support for new formats.

We rewrite the whole thing?

I do not think it is realistic.

Improve processes

Pull requests don't get reviewed and cannot be merged

When I had lot of spare time to work on Exiv2 (in a period in which I was switching jobs) this is what I found more annoying about our process. For big changes, I think it is fine to establish some "grace period" for a review. But most of the times we are fixing small bugs or making small improvements here and there which should not be blocked for so long. From my point of view, anyone with admin rights in the Exiv2 group, should have freedom and the good judgement to merge something quickly when the changes are mostly cosmetic or when we are dealing with fixing something in CI (just the first examples that came to my mind). In case one of these persons abuse this power, we could analyse the behaviour and decide what to do.

CI is flaky and breaks, only one person can fix it (@D4N for GitLab, @piponazo for Appveyor). If the person is busy, PRs are red and cannot be merged disappointed. => We could move the tests to github actions, so that everyone has access to them and can fix the issues.

Would it not be possible to move the permissions of Gitlab, TravisCI and Appveyor to the Exiv2 team instead of being me and @D4N the owners of these services? I will investigate with TravisCI and Appveyor (I was the one adding those services to Exiv2).

PR reviews are merciless and annoying because a lot of minor stuff gets flagged. I am the culprit in this case. If this is a stop gap for many, then I will stop reviewing PRs in detail and instead amend them to fix issues that I find need fixing (provided I have time).

I do not think this is something bad per se. I particularly always appreciate the time people dedicate to review the code I am submitting, and if the suggestions made are good, I always try to address the challenges. I also know by experience that this is not the most common way to react to the code reviews, and some people gets are less open to change things (for whatever reason).

Something that I proposed in few companies where I have worked is to tag the comments with labels indicating the importance of the comment. Something like:

I would say that we could try to be a bit more indulgent in some cases (contributors do not have much spare time or have difficulties with Git), and approve PRs unless there are open comments tagged with [bug/leak/blocker]. Then, for the project maintainers it would take probably few minutes to address the other less important comments.

phako commented 4 years ago

btw... The Coverity page needs some love. It has been last updated with v0.25 https://scan.coverity.com/projects/exiv2

phako commented 4 years ago

For attracting new contributors, I recently learned about https://up-for-grabs.net/#/ - maybe that helps to get people interested?

ghost commented 4 years ago

Just sent out a link to this issue across the Glimpse project communication & social media channels. Hopefully some of the hype we've drummed up will do you some good as well. :)

cryptomilk commented 4 years ago

Code review is important to keep a high standard of code quality. It is important to ensure that there are no new bugs introduced and things don't break. Yes, it is not a task any developers wants to spent most of if times on. When I request a review for a new merge request I also have to review the code from someone else.

For fuzzing and also security related fixes it is important to have the process documented. You can use: https://www.libssh.org/development/security-process/

Write down which versions you support and communicate that. Example: https://wiki.samba.org/index.php/Samba_Release_Planning

This way you can always point people to your processes. The smaller the team the less versions you should have in maintenance mode.

I hope that helps.

CarlSchwan commented 4 years ago

Disclaimer: KDE dev and indirect user of Exiv2 ;)

Hello, another possibility for Exiv2 would be to be integrated into a bigger community (KDE, GNOME or Free Desktop) and use the infrastructure provided by this community.

In the case of KDE, this would allow the Exiv2 developers to use the server infrastructure (Jenkyll CI or gitlab CI, site hosting, release team, promo team, translations, sysadmin, ...). Joining a bigger community could also help because devs from other projects can help with reviewing merge request.

For KDE we have an incubating process, documented here: https://community.kde.org/Incubator. I don't think Exiv2 will have problem passing the incubation, since we are already using Exiv2 in a lot of place: KFileMetadata, Baloo, Dolphin's information panel, Digikam, Gwenview, and probably more :D

CCing more people @jriddell @Pointedstick who can give more details

Pointedstick commented 4 years ago

I know that some KDE contributors have sent patches, so it seems that there's some overlap in skills already. It might be a good match. If you folks are interested, I would be more than happy to help with the incubation process!

cgilles commented 4 years ago

Hi KDE guys I already proposed this kind of migration 10 years ago without success. The proposal was not addressed at right moment in the project life. Migrating is always time consuming, and where a project is growing quickly, this will introduce a time latency in release plan. One big advantage to migrate to KDE infra is the big translators team which will internationalize well the library and the CLI tools. This kind of migration will permit also to see the project maintained by a large community of developers from KDE family. So, i vote for this idea. Gilles Caulier

phako commented 4 years ago

Since it is quite widespread indirectly in GNOME, if you can guarantee to keep Qt out of it, KDE might be a good place, otherwise maybe freedesktop is probably better.

Edit: That wasn't meant to bash on Qt. It's more of a practical thing relating to Gtk and Qt mixing together being a bit weird on a technical level

D4N commented 4 years ago

Hi folks,

thanks for all these comments!

A few comments to some replies:

from @phako:

* What exactly was the Jenkins doing for releases that cannot be replicated by other means of CI?

Jenkins was/is building the releases of exiv2 that get published. It can surely be replicated with any other CI, we just haven't set this up yet.

* I'd suggest to drop old unmaintained code, which you've already started on master. Do only meta-data.

:+1: 

* If there's a rewrite, it needs to be consumable by C/C++ which rules out most of the "sexy" languages anyway. The only way I can actually think of would be a gradual conversion to Rust.

That was my idea too, Rust is very tempting, but a rewrite is not realistic unless a bunch of experienced coders step up and drive this forward.

* I'd also be interested in getting HEIC/HEIF support as well; I was following the PR but lost track

Currently licensing is a blocking that PR (and that it had absolutely zero tests last time I checked).

* TBH, I found the setup of the exiv2 project a tad weird. It's missing some basic infrastructure I am used to from other projects, like a user's / developers discussion forum (whatever form). Things certainly got more obvious with the move to github, though.

As a reaction to this, I've created a public chatroom on matrix.org: #exiv2-chat:matrix.org, a discussion mailing list: ~d4n/exiv2-discussion@lists.sr.ht, an announcement mailing list https://lists.sr.ht/~d4n/exiv2-announce and a patches mailing list: ~d4n/exiv2-patches@lists.sr.ht.

* Unfortunately for you, the initial decision for GPLv2, while encouraged by the FSF or rather RMS for libraries instead of going for its Lesser cousin limits corporate adoption. I suppose that this was done to encourage the use of the commercial license for those use-cases. Even more unfortunate is that this isn't something that can easily be changed without a massive headache

Actually we are using GPLv2+, so that would make an integration with e.g. libheif a little simpler, but changing the license is completely off the table as we lack the necessary team of lawyers.

from @clanmills:

exiv2.dyndns.org is gone. The release is on https://exiv2.org and the pre-release on https://pre-release.exiv2.org

A couple of obvious points about v0.27.3 (and later v0.27 dots)

1. You can publish source releases on GitHub without updating exiv2.org

2. If you publish releases on GitHub, I'm willing to update exiv2.org and build the binaries with Jenkins on the MacMini, if (and only if) the web and release code is stored on SVN.  I've retired because of frustration with review/git/github.

Thanks for the offer, however that will only defer the inevitable: we must be able to create a release without Jenkins. So I'd like to give this a try without Jenkins first, but keep it as a plan B.

from @piponazo:

Ensure that we can produce a 0.27.3 release by the end of 2019: create releases on our current CI without Jenkins. A prerequisite for that is that we can build exiv2 in a reproducible fashion (which is possible, openSUSE is already doing that with one patch).

I think it should be possible to generate the binary artifacts for 0.27.3 from travisCI and Appveyor. I could dedicate some to this topic in the next days/weeks. I remember that long ago we discussed about some security issue in travisCI regarding the deployment of binary artifacts and that's we discarded that option. Opinions about this ?

Travis has had issues in the past with disabled package verification, meaning that adversaries could (in theory) manipulate your build environment.

Nevertheless, I would never trust a cloud provider as the only source of my binaries, unless they can be built reproducible and I can verify them locally. That's what I'd like to achieve: we built exiv2 inside a trusted container locally and on Travis/GitLab/Github and verify that the results are the same. Then Travis can host the artifacts and we are certain that they haven't been tampered with.

Migrate all existing svn repositories that are still out there to git under the Exiv2 org

I am not sure to what are you referring to here. Would you mind to develop a bit more this?

Afaik the website code and some additional tests still exist in svn repos somewhere.

Long term steps

Drastically reduce the scope of Exiv2 to match only what our API consumers require

I think this is matching we some of the previous actions we have taken on master: i.e, to drop stuff not related with Image Metadata. Of course, any suggestions to keep improving the API would be welcomed.

Definitely. Large parts of the API have not been designed with RAII in mind and the io system needs imho a rewrite.

We find new contributors. Imho unfortunately rather unlikely, as the past showed. We can try to raise awareness about exiv2, but unfortunately I don't really know how to make this project appealing to new contributors.

Not sure either about how to find new contributors. Exiv2 has been for me the first open source project in which I participate regularly. Somehow, after working on it for several months I felt responsible of addressing bugs and improving some specific areas ... I guess that newcomers would be interesting in addressing more interesting topics, such as adding support for new formats.

Newcommers like to work on easy bugs, on interesting topics and on clean and well documented code bases. I'm afraid we aren't really shining here.

Improve processes

Pull requests don't get reviewed and cannot be merged

When I had lot of spare time to work on Exiv2 (in a period in which I was switching jobs) this is what I found more annoying about our process. For big changes, I think it is fine to establish some "grace period" for a review.

I agree, if a pull request doesn't get reviewed for n-weeks, then a collaborator can merge it, provided there were no objections and they sent out a few reminders.

But most of the times we are fixing small bugs or making small improvements here and there which should not be blocked for so long. From my point of view, anyone with admin rights in the Exiv2 group, should have freedom and the good judgement to merge something quickly when the changes are mostly cosmetic or when we are dealing with fixing something in CI (just the first examples that came to my mind). In case one of these persons abuse this power, we could analyse the behaviour and decide what to do.

To be honest: I don't like this proposal. Merging a PR without a review should imho be the last resort and not something that you are allowed to do on a regular basis. If this is something really urgent (like a broken CI blocking 10 PRs), then so be it, but otherwise it just becomes too tempting to not wait for a review and just merge the PR "because I don't want to wait".

CI is flaky and breaks, only one person can fix it (@D4N for GitLab, @piponazo for Appveyor). If the person is busy, PRs are red and cannot be merged disappointed. => We could move the tests to github actions, so that everyone has access to them and can fix the issues.

Would it not be possible to move the permissions of Gitlab, TravisCI and Appveyor to the Exiv2 team instead of being me and @D4N the owners of these services? I will investigate with TravisCI and Appveyor (I was the one adding those services to Exiv2).

It's not really a problem of permissions (that's trivial to solve), but rather the general knowledge of the underlying platform. The CentOS CI for instance has been broken for a few weeks, because CentOS removed the python36 binary and replaced it with python3. The fix was simple, but still I've fixed it because I set this thing up and knew how it works. The same would happen with Appveyor: I have neither a testsystem nor the knowledge to fix issues on Windows (see #898, that one is blocked by some MSVC oddity that I do not understand).

So I'd rather like to simplify and unify our CI setup, so that more team members can actually fix the CI.

PR reviews are merciless and annoying because a lot of minor stuff gets flagged. I am the culprit in this case. If this is a stop gap for many, then I will stop reviewing PRs in detail and instead amend them to fix issues that I find need fixing (provided I have time).

I do not think this is something bad per se. I particularly always appreciate the time people dedicate to review the code I am submitting, and if the suggestions made are good, I always try to address the challenges. I also know by experience that this is not the most common way to react to the code reviews, and some people gets are less open to change things (for whatever reason).

Something that I proposed in few companies where I have worked is to tag the comments with labels indicating the importance of the comment. Something like:

* [minor] : Something that could be improved, but that is really a minor thing. Nothing would happen if it is not changed.

* [style, naming]  : Cosmetic things. [naming] is normally about improving code readability. [style] is about following the project guidelines / style. Not considered as blocking issues, but it would be nice to address.

* [bug/leak] : Problems detected in the new code. Need to be addressed before accepting.

* [important / blocker] : Not a bug or leak, but something it is extremely important from the point of view of the reviewer, and it should be addressed before the PR is accepted.

This sounds like a very good idea!

I would say that we could try to be a bit more indulgent in some cases (contributors do not have much spare time or have difficulties with Git), and approve PRs unless there are open comments tagged with [bug/leak/blocker]. Then, for the project maintainers it would take probably few minutes to address the other less important comments.

I'd suggest that we instead fix the issues directly in the PR (usually contributors keep the "allow edits from maintainers" option selected) to prevent a huge backlog of "fix this minor thing" issues.

from @phako

For attracting new contributors, I recently learned about https://up-for-grabs.net/#/ - maybe that helps to get people interested?

Sounds good, I'll add us there and to https://www.codetriage.com/ and will try to create a few more easy onboarding issues.

from @TrechNex

Just sent out a link to this issue across the Glimpse project communication & social media channels. Hopefully some of the hype we've drummed up will do you some good as well. :)

Thank you!

From @cryptomilk:

Code review is important to keep a high standard of code quality. It is important to ensure that there are no new bugs introduced and things don't break. Yes, it is not a task any developers wants to spent most of if times on. When I request a review for a new merge request I also have to review the code from someone else.

The issue at hand is that we often run into the situation that dev A has time to code but dev B has no time to review and so PRs are left rotting.

For fuzzing and also security related fixes it is important to have the process documented. You can use: https://www.libssh.org/development/security-process/

Write down which versions you support and communicate that. Example: https://wiki.samba.org/index.php/Samba_Release_Planning

This way you can always point people to your processes. The smaller the team the less versions you should have in maintenance mode.

I hope that helps.

I've created #1035 to track progress the progress for this.

from @ognarb:

Disclaimer: KDE dev and indirect user of Exiv2 ;)

Hello, another possibility for Exiv2 would be to be integrated into a bigger community (KDE, GNOME or Free Desktop) and use the infrastructure provided by this community.

In the case of KDE, this would allow the Exiv2 developers to use the server infrastructure (Jenkyll CI or gitlab CI, site hosting, release team, promo team, translations, sysadmin, ...). Joining a bigger community could also help because devs from other projects can help with reviewing merge request.

Yes, I was thinking about integrating exiv2 tighter into either the Gnome or KDE ecosystem. I've created #1036 to move the discussion there.

cgilles commented 4 years ago

About possible Rust port of the library : for me it's a non-sense ! The C++ code base is enough mature, become really stable and C++11 and later come with real improvement with will be enough for the future of the project.

For me Rust is not the future so far... Try to rewrite this project with this language and you will be sure that the project will be forked immediately.

Best

Gilles Caulier

D4N commented 4 years ago

About possible Rust port of the library : for me it's a non-sense ! The C++ code base is enough mature, become really stable and C++11 and later come with real improvement with will be enough for the future of the project.

For me Rust is not the future so far... Try to rewrite this project with this language and you will be sure that the project will be forked immediately.

Well, GNOME did that for librsvg and the world didn't end for them. Also, I'd only start with the internals first, so that the API stays the same and you don't even realize that you are using Rust.

But let's not get into bikeshedding here, currently we completely lack the manpower for such an undertaking. On the other hand, I definitely wouldn't be opposed to introducing Rust into our code base.

cgilles commented 4 years ago

Maintaining 2 lead code code base will be the hell in time. This will require manpower, and it's not the case for a small open source team. It's already difficult with one lead language, so with 2 it's surrealist.

And i'm not interested by Rust stuff... why to reinvent the wheel again and again with new language. it's a waste of time. Concentrate the effort to fix the bugs and advance the project, this is the plan.

Gilles Caulier

dpronin commented 4 years ago

Hi guys, Is there planned a release 0.27.3? If there is, when? PS: I need this library with c++17 capable of compiling, 0.27.2 is c++14 compatible only Thank you

clanmills commented 4 years ago

Folks:

I'm thinking about working on Exiv2 v0.27.3. I won't be extending the scope to include C++14 or Rust. It will be a maintenance release of the Exiv2 v0.27 family. It was almost ready in October when I became totally frustrated by having about 10 outstanding PRs which hadn't been approved. In the last week I've enjoyed working with @boardhead on #1046.

I don't think it's a lot of work to get v0.27.3 ready. However "not a lot of work" could take a couple of months as I would want to publish release candidates. So, I'm thinking to announce that Exiv2 v0.27.3 is scheduled for the end of June 2020. I'm also contemplating that Exiv2 v0.27.4 will be the final release of Exiv2 v0.27 in June 2021.

If you'd like to help with this effort, I would highly value your input and in particular your code reviews. However, we have to agree that PRs will be approved after 5 days unless there are outstanding code review discussions.

Why am I coming back out of retirement to do this? I don't want to see Exiv2 die and development in 2020 has been slow. I understand the work/home/life pressure on Team Members. If I make "dot releases", that will remove the pressure on you to deliver v0.28. I am rather hoping that the covid situation will ease your work/commuting time and you will also have time to work on Exiv2.

When I was working on v0.26, I was forced to take a couple of breaks of two months to deal with house remodelling matters. As soon as I returned the project, the amount of user support would suddenly increase. I've noticed that user support issues on GitHub have slowed down in 2020. If my activity on Exiv2 v0.27.3 attracts more user support queries, that will also consume my time.

Anyway. The offer is that I will prepare Exiv2 v0.27.3 for release in June 2020. @D4N @piponazo @kevinbackhouse will you support (or at least not frustrate) my efforts to achieve this goal?

sridharb1 commented 4 years ago

Thanks Robin.

I am more interested in supporting video as well as new formats like HEIF. I would like support for cameras to track exiftool if possible. Unfortunately, I don't see that happening soon (no real judgment here, just an observation).

If I am able to do something in that area, then I will upload it to my fork of exiv2 (which currently has two small changes dealing with custom XMP tags that I have need).

BTW, I have uploaded my Visual Studio solution/project files that compiles with every conceivable option of exiv2 turned on, https://github.com/sridharb1/exiv2-x86_x64

clanmills commented 4 years ago

Exiv2 v0.27.4

Topic More Info
Remaining https://github.com/Exiv2/exiv2/milestone/6
Completed https://github.com/Exiv2/exiv2/pulls?q=is%3Apr+is%3Aclosed+milestone%3Av0.27.4

Exiv2 v0.27.4 Features

  1. bmff support (.CR3, .AVIF, .HEIC, .HIF, .JXL/bmff) files.
  2. Rewrite 0.27 bash test scripts in python.
  3. Support for Exif 2.32 and DNG 1.6.
  4. Crowdin Localisation Support
  5. Completion of Image Metadata and Exiv2 Architecture https://clanmills.com/exiv2/book/
  6. Improved documentation.
  7. Various minor bugs and fixes.
  8. RC3 issued to deal with 12 security issues. After 18 months without a CVE, we were attacked between RC2 and GM.
  9. Security policy defined and published on GitHub.

Exiv2 v0.27.4 Dedication

To Lizzie (our cat) who was put to sleep on 2021-02-13. I will love her always.

Exiv2 v0.27.4 Acknowledgements

Contributor Activity
Alex Project Management
Arnold Keeps me honest!
Christoph Nikon and Canon Support
David Help with legal investigation concerning bmff
Freddie Fuji support
Kev Security fixes
Leo New python test scripts
Leonardo Crowdin Localisation Support
Luis C++ modernisation
Miloš DNG, Exif 2.32, easyaccess support
Nehal Exiv2.org maintenance
Peter K bmff code
Peter S langAltValue.read() fix and helpful issue reports
pydera Security Fixes

If I've failed to acknowledge your contribution, I apologise. Please email me and I will add you to this table.

Exiv2 v0.27.4 Release Notes (updated 2021-06-15)

More items will be added to this table as they arise.

Group PR Topic Issue
Bugs &
Fixes		 #1475
#1490		 bmff Base Media File Format #1229
#1489
#1716 Exiv2 v0.27.4 GM
#1517
#1513		 JPX/bmff support #1503
#1528
#1540
#1681		 Revision notes and Version String
#1657 Quadratic complexity performance bug
#1648 Update bmffimage.hpp include order and path
#1624 Fix Valgrind CI
#1518 Changes Exiv2::enableBMFF() API #1508
#1519 samples/metacopy.cpp optstring #1504
#1512 Avif file -ps image_size fix #1512
#1493 v0.27.4 application tests
#1486 Empty Exif Ascii handling #1484
#1482 Issues with LangAlt command-line parsing #1481
#1480 DNG 1.6 triple-illuminant calibration tags
#1469
#1472		 Sony 2010e tag support #1464
#1471
#1461 cppcheck detected performance issues #1459
#1444 Fix comment typo is xmpprint.cpp
#1442 Test Nikon LensData v8 handler #1437
#1433
#1432 Binary output handling #1431
#1436 DNG 1.6 Support
#1427 prettyPrint Planar Config
#1425 fix some Nikon MarkerNote short/long tags
#1412 DNG 1.5 Support
#1411 Fix Fuji tag type #1344
#1410 bump revision 0.27.4.9
#1409 Support hidden embedded TIF in RAF #1402
#1407 Support Fuji CropMode
#1399 Sony Lens aberration correction parameters
#1392 DNG 1.3 #1393
#1391 DNG Changes
#1389 Exif 2.32 Support #929
#1384 Disable exiv2 option --binary
#1386 Adding more easy accessors #1385
#1054
#1360 base64 decode fixes #1358
#1342 PSD fixes #1261
#1331 Remove BigTiff Support #1329
#1330 formatString fixes #1328
#1314 ASAN issues with RemoteIo #1307
#1313 crwtest fixes #1297
Security #1483 Define Security Policy #1122
#1606 Initialise _binary in actions.hpp
#1592 Prevent large alloc() by malicious file
#1591 Fix loop caused by subBox.length==0
#1675 out-of-bounds-read bmffimage.cpp
#1627 readOrThrow check result from io.read()
#1587 bounds check++ Jp2Image::encodeJp2Header
#1581 bounds check in WebPImage::doWriteMetadata
#1577 bounds check in JpsImage::enclodeJp2Header
#1539 Integer overflow #1530
#1533 Out of buffer access #1529
#1529 heap-buffer-overflow Jp2::doWriteMetadata #1587
#1523 jp2image exiv2 asan issue #1522
Lens #1375 Olympus M.Zuiko Digital ED 17mm F1.2 Pro
#1373 Sigma 18-35mm f/1.8 DC HSM
Build #1496
#1498		 Exiv2 v0.27.4 RC1
#1500 make uninstall issues warnings #1499
#1452 Building on windows/msys2 #1449
#1439 Fix PACKAGE_URL and PROJECT_DESCRIPTION
#1434 CI build MinGW/msys2 and Cygwin
#1367 CI changes for Linux
#1356 MinGW/msys2 toolchain changes #1353
#1339 Cygwin Stack Protection
#1336
#1349
#1340		 Winsock2 include changes #1335
#1309
#1311		 Remove EXV_HAVE_STDINT_H check
#1290 Solaris Stack Protection
#1277 Remove cmake -DEXIV2_BUILD_PO option #1276
#1275 GNUInstallDirs changes
#1271 Correctly setting -fstack-protector-strong #1252
#1245 More compiler flag settings #1243
#1268 Fix GPSProcessingMethod handling #1266
#1260 Writing PSD Files
#1253 Disable libiconv/Visual Studio/CMake
Test #1477 Fix exiv2-test.sh output if test/tmp empty #1477
#1372 Support env EXIV2 strings in python tests
#1371 Test NLS Support #1278
#1333 Test stdin
#1257 Rewrite bash test script in Python #1215
#1289 Remove env EXIV2_EXT
#1372 Support env EXIV2 strings in python tests
#1495 Remove test dependency on make and bash #1274
Various Rewrite bash scripts in python3 #1215
Localisation #1435 ES Translation
Documentation #1715 Broken example in man page #1285
#1440 Fix typo in cmd64.bat in Documentation
#1414 Web-site issues
#1403 Visual Studio 2019 buildnotes #1394
#1400 IPTC tag corrections on web-site #1393
#1387 Fix man page typos concerning CanonFi
Withdrawn
No action		 Discussion FLIR Camera Support #1479
Canon delete thumbnail corrupts tags #1589
Never action a CVE once RC1 has shipped #1683
BMFF/JPEG-XL patent discussion #1679
bmff test failures on 0.27.3.9 (ok on RC2) #1680
WIN_UNICODE API not in on-line docs #1656
Reporting different Lens for CR3 files #1639
exiv2.org is down #1604
building with emscriptem #1602
Exiv2.org future plans #1574
Olympus OM-D E-M10 Mark III and ~/.exiv2 #1544
#1527 Test Suite to ignore errors #1502
Include path discussion #1516
Sigma 60-600mm f/4.5-6.3 DG OS HMS | Sport #1478
#1474
#1458		 Withdrawn PRs concerningin bmff #1229
Nikon d780 + Tamron 85mm 1.8 VC #1468
Exif.Photo.DateTimeOriginal discussion #1467
Question about sidecar files #1465
asfvideo.cpp null pointer dereference #1463
Multi-Page TIFF Support #1460
Lumix G 20mm F1.7 II Asph. #1441
Canon Lenses #1429
CMake issues with Xcode 12.2 -G Xcode #1408
#1286 Exiv2::XmpProperties::propertyList() #1206
#1226 XMP false report #1223
API Compatibility Test #890
Team
Discussion		 Future of Exiv2 #1466
Project Status #1462
Open Invention Network #1447

The Plan at Project Outset

We had a meeting with darktable on 2021-01-09 to discuss ISOBMFF/CR3 support which will require Exiv2 to release v0.27.4. Alex prepared the slides for the discussion.

Exiv2-ISOBMFF-2021-01-09.pdf

The mood in the room was excellent. Everybody was positive and confident that the project will be a success.

In January and February:

  1. Peter and Robin will port the CR3/HEIF/AVIF code from my book to Exiv2
  2. Robin will finish the book
  3. Roman will work on rawspeed/CR3.
  4. Alex and Robin will investigate/implement new CR3 tags.
  5. Alex and Robin will investigate taking Exiv2 into OIN. As Canon is a member of OIN, we are confident that we are on solid legal ground for CR3.
  6. Team Effort to test bmff support.

I'm not sure what rawSpeed/darktable intends to do about HEIF. I'm confident that the code in my book to read the unencrypted metadata in HEIF is legal.

In March, I'll release Exiv2 v0.27.4 RC1 by 2021-03-31 and darktable will make a pre-release build for user testing in April.

Once darktable testing is complete, the code will be promoted to the darktable 'master' branch and will ship in the next annual release. As bmff/CR3 Support is a much requested feature, the annual release may ship early if 'master' is sufficiently stable.

Exiv2 v0.27.4 Schedule and Task List

Date Milestone Comment
2021-02-28 v0.27.4.9 Code Complete
2021-03-31 v0.27.4 RC1 darktable to integrate
2021-04-30 v0.27.4 RC2 Code Freeze
2021-05-21 v0.27.4 GM Done

Lizzie_2021-02-09_23 37 38

boardhead commented 4 years ago

Bravo!

piponazo commented 4 years ago

@clanmills I'm very happy to see you back! Of course, I'll support you the best I can with code reviews when you need it. Feel free to add my to your PRs as reviewers, so I get notifications about them.

sridharb1 commented 4 years ago

Thanks for the update, Robin. Hope it all goes well.

clanmills commented 4 years ago

@piponazo I'll be delighted to receive your reviews. Thanks. And I see you've "powered up" on several issues this morning. I see that Andreas (Schneider) has been busy also on libssh. This "lock-down/work-at-home" could be good for open-source.

clanmills commented 4 years ago

Topic: Exiv2 and ISOBMFF Support Time: Jun 14, 2020 13:00 London

Join Zoom Meeting https://us02web.zoom.us/j/82136730279?pwd=M3hCbll4cWN3ellJd2pCZkxjVEx3Zz09

Meeting ID: 821 3673 0279 Password: 1fDNUV

clanmills commented 4 years ago

Here's the summary of the Sunday's meeting on Zoom. https://github.com/Exiv2/exiv2/issues/318#issuecomment-643794988

clanmills commented 3 years ago

My priority in 2020 is to get the book finished. https://clanmills.com/exiv2/book/

I'm willing to be the release engineer for one more release of Exiv2 in 2021. Either 0.27.4 or 0.28. The earliest dates for the next release are RC1 2021-03-01, RC2 2021-04-01, and GM 2021-05-01. Ready for the LGM conference in Rennes in May.

Scope of v0.28 v0.28 has a new API and most applications using the library will probably require code changes.

v0.28 would be the new C++11 API. All PRs from 0.27-maintenance will be included. We will probably give the code a 100% reformat to contemporary style. 100% python test suite.

I would also very much like to see ISOBMFF (CR3, HEIF, AVIF) added if somebody manages the legal work. We also need an engineer to either port relevant code from my book, or to merge a PR which claims to provide this support. There are numerous topics discussed in the book that could be ported to v0.28 if we have sufficient engineering resources. For example: support for BigTiff, extended JPEG metadata (>64k) and discontinuing to use memory mapped files.

Scope of v0.27.4 I don't know of any security issues in 0.27-maintenance. There are numerous bug fixes on maintenance-0.27 The test suite will be 100% python. So v0.27.4 would a "complete release" of all patches and bug fixes since v0.27.3 shipped on 2020-06-30.

If we release v0.28, we may decide to also release 0.27.3.1 which would be 0.27.3 + security fixes. The purpose of such a release is to distribute security fixes for users of the "classic" Exiv2 API.

D4N commented 3 years ago

I was pointed towards this consultancy which could help out: https://changeset.nyc/ (but they won't do this for free obviously).

clanmills commented 3 years ago

Thanks, @D4N. We're in good shape on this. There's an organisation called Open Invention Network: https://openinventionnetwork.com The next maintainer should take Exiv2 into that and be part of the "Linux System Definition". I believe that will take care of the legal situation.

The code to read ISOBMFF (.cr3, .heic, .avif and .jp2) is documented in my book and working well. So the way forward for ISOBMFF support is open.

As of yesterday, I consider myself retired from Exiv2 and do not intend to do any further work of substance. We're off to Cornwall on Friday for a week with the grand-kids (and their parents). I'll get the book finished in 2021.

As and when a new maintainer for Exiv2 comes forward, I will give them every support and encouragement.

I have given you and @piponazo and Andreas Huggel great praise in the book for your outstanding work on Exiv2. And I've acknowledged Gilles, Andreas S and about 20 other folks with whom I shared my Exiv2 adventure. If you (or any of the gang) are in England, Alison and I will be honoured for you to visit and stay with us.

D4N commented 3 years ago

Robin Mills notifications@github.com writes:

Thanks, @D4N. We're in good shape on this. There's an organisation called Open Invention Network: https://openinventionnetwork.com The next maintainer should take Exiv2 into that and be part of the "Linux System Definition". I believe that will take care of the legal situation.

The consultancy I posted is unrelated to legal issues, it's more about how to help the project actually find said new maintainer. The legal issues can be ironed out, I'm certain of that. But finding a person willing to maintain exiv2 is the hard part.

clanmills commented 3 years ago

Thanks @D4N. A maintainer has been discussed (without success) here: https://discuss.pixls.us/t/maintainer-urgently-needed-for-exiv2/21547/23 changeset is interesting. No idea how that could be funded.

I'm not going to let finding a maintainer bother me. If somebody comes forward, that's fine. If not, c'est la vie. As you said on Monday "I have to get it go". I agreed with the family that I will finish with Exiv2 by my 70th birthday on 2021-01-18. I'll achieve that (with hours to spare). I'm now focused on the book and the project is off my back.

sridharb1 commented 3 years ago

Thanks for the update Robin. Personally, I will be interested in this release because I am switching to Canon R5 which has support for HEIF images. Though other parts of my workflow are still JPG-reliant (like Picasa), maybe one day darktable will catch up. Specifically, I find the state of faces support in darktable the main reason for me not to migrate, but I would also love to move to a reasonably supported platform instead of a dead one like Picasa.

clanmills commented 3 years ago

Happy New Year, @sridharb1 Let's hope C19 fades fast in 2021.

Are you sure that Canon R5 uses HEIF? I thought it was CR3. Exiv2 v0.27.4 will support both. I now have a splendid collection of 10,000+ test images from a variety of sources including https://raw.pixls.us where I got:

541 rmills@rmillsmm-local:/Users/Shared/Jenkins/Home/userContent/testfiles $ finder "*.cr3" | grep R5
./Pixls/Canon/Canon/Canon EOS R5/eos_r5_raw.CR3
./Pixls/Canon/Canon/Canon EOS R5/eos_r5_craw.CR3
./Pixls/Canon/Canon/Canon EOS R5/eos_r5_raw_dualpixel.CR3
./Pixls/Canon/Canon/Canon EOS R5/eos_r5_craw_dualpixel.CR3
./Pixls/Canon/Canon EOS R5/eos_r5_raw.CR3
./Pixls/Canon/Canon EOS R5/eos_r5_craw.CR3
./Pixls/Canon/Canon EOS R5/eos_r5_raw_dualpixel.CR3
./Pixls/Canon/Canon EOS R5/eos_r5_craw_dualpixel.CR3
542 rmills@rmillsmm-local:/Users/Shared/Jenkins/Home/userContent/testfiles $

The book will soon be finished. The Exiv2 adventure will finish in 2021. It's time to "let go". I also regret the passing of Picasa.

sridharb1 commented 3 years ago

Thanks Robin and best wishes for the new year.

Yes, R5 (and I believe R6) and possibly also their flagship 1DXMarkIII have support for HEIF. 10-bit, I think with HDR PQ instead of the some other non-standard HDR formats used in other cameras including Apple. I am looking forward to moving on from JPG.

CR3 is their new RAW format.

clanmills commented 3 years ago

If you get the camera before Exiv2 v0.27.4 GM is released (schedule: 2021-05-22) be sure to test your HEIF images and donate some images to https://raw.pixls.us. I have very few HEIC test images at present.

That Canon will support HEIF is good news because Canon are a member of OIN (a non-aggression patent alliance). Part of the Exiv2 v0.27.4 project is to investigate joining OIN and being included in the "Linux System Definition". https://openinventionnetwork.com/linux-system/

You may be aware that several members of Team Exiv2 objected strongly on legal grounds to ISOBMFF support being added to Exiv2 v0.27.3. The data in an image is the property of the owner of the camera. It's likely that many components of the camera including the retail packaging are protected by patents which are not infringed by Exiv2. I can't see how reading unencrypted metadata can be a violation of a video/image encoding patent.

The code in my book that decodes ISOBMFF (.CR3, .HEIF, .AVIF) was written after studying the ISOBMFF Spec w15177. Numerous open-source projects including ExifTool, Python and ISOBMFF Explorer offer similar code and there has been no adverse report of legal action.

sridharb1 commented 3 years ago

Happy to help, but, the controlling factor will be availability, which is very spotty at the moment, even though the camera officially announced in July and was available first in September. Given that it is a semi-professional camera, I am sure that first stocks will go towards satisfying markets like US, Canada, Western Europe etc. India might not see it till maybe Q2 of next year. However, I am sure that there will be plenty of images posted from where we can get some test cases with permission.

I have always agreed with your POV on this issue. I don't foresee any legal issues.

clanmills commented 3 years ago

Exiv2 v0.27.5 RC2

PR Topic Issue Group
#1889 Avoid reading trailing byte in string None Security
#1884 Throw if preview is greater than 1MB #1881 Security
#1880 XML validation #1877 Security
#1873 Trigger CI None Build
#1870 Update 27.5 docs None Documentation
#1862 Fix macOS workflow None Build
#1861 Add doc to release workflow None Build
#1860 Update version: 0.27.5 RC1 None Build
#1859 Enable BMFF in Actions workflows None Build
#1857 Fix compiler warning on Apple/M1/Clang #1856 Build
#1854 Back-port actions and fuzzer to 0.27-maintenance None Build
#1828 Check value is in range before casting from double to uint32_t #1827 Bug

Exiv2 v0.27.5 RC1

Topic More Info
Download https://pre-release.exiv2.org
Remaining ( 0) https://github.com/Exiv2/exiv2/milestone/9
Completed (57) https://github.com/Exiv2/exiv2/milestone/9?closed=1

Exiv2 v0.27.5 Features

  1. Security fixes
  2. BMFF bug fixes
  3. libFuzzer target (for improved security testing)
  4. Minor bugs and fixes

Exiv2 v0.27.5 Acknowledgements

This release is due to Kev, supported by the rest of the team. Thank You, Kev for your hard work and attention to detail.

Contributor Activity
Alex Project Management
Christoph C++ code
Kev Outstanding work on security and other issues
Luis C++ modernisation
Miloš C++ code
Peter K C++ code
Peter S C++ code
Robin Release engineering

If I've failed to acknowledge your contribution, I apologise. Please discuss it on the chat server and you will be added to this table.

Help Wanted

Team Exiv2 is a happy little band of enthusiastic engineers. We have several tasks for which we're looking for volunteers.

  1. Extended test coverage.
  2. Use of Coverity Scan (static code analysis).
  3. Release Engineer.

If you'd like to contribute to Exiv2, please talk to us on the chatserver: https://matrix.to/#/#exiv2-chat:matrix.org

What's next for Exiv2?

Nothing is actually scheduled beyond v0.27.5

  1. Exiv2 v0.27.5 GM 2021-09-30
  2. Probably another dot for v0.27. Spring 2022 maybe.
  3. Exiv2 v1.00. Summer 2022 maybe.

Exiv2 v0.27.5 RC1 Release Notes (updated 2021-08-10)

More items will be added to this table as they arise.

Group PR Topic Issue
Bugs &
Fixes		 #1855 Enforce BMFF box nesting
#1848 Assert->error TiffDirectory::doWriteImage #1847
#1846 Assert->error TiffDirectory::writeDirEntry #1845
#1844 malloc->DataBuf WebPImage::decodeChunks #1841
#1840 Check float within int range before cast #1838
#1834 Assert->error TiffMnEntry::doCount() #1833
#1831 Safer cast double to long in value.hpp #1827
#1828 Check double in range before cast to uint32_t #1827
#1820 Check string isn't empty #1819
#1818 Fix memory leak in pngimage.cp #1817
#1816 check to prevent out-of-bounds read in memcmp #1815
#1814 jp2image.cpp: check size before allocation #1812
#1796 Check embedded RAF image is really a TIFF #1791
#1790 bufRead needs to be adjusted after seek()
#1789 &bytes[0] (std::vector) will crash if empty
#1788 Ensure read complete to prevent infinite loop
#1765 Add Exif.Image.PageName tag
#1758 Check iterator is not end() after findKey
#1752 Fix incorrect loop condition
#1745 avoid processing MOV files when BMFF enabled
#1739 Fix assertion failure in crwimage_int.cpp
#1737 Zero initialize local variables
#1735 Use vector::at() rather than operator[]
#1720 Stricter date parsing in value.cpp
Security #1769 Safer std::vector indexing
#1778 Fix infinite loop Image::printIFDStructure
#1767 Prevent loop counter wrap around
#1759 Better bound check in Jp2Image::printStructure
#1750 Avoid integer divide by zero
Lens
Build #1866 include search path fix #1516
#1862 Fix macOS workflow to use gtest 1.8.0
#1861 add doc to release builds
#1860 Exiv2 v0.27.5 RC1
#1859 Enable BMFF in Actions workflows
#1858 Fix compiler warning on Apple/M1/Clang #1856
#1854 Actions and fuzzer for 0.27-maintenance
Test #1853 Use @unittest.skip for ASAN builds #1821
#1754 Fix Ubuntu20.04/Release/Sanitizer test breaker
XMPsdk #1821 memory leak in addBinding (xmlparse.c)
Localisation
Documentation #1865
#1867
#1868		 User documentation update
Withdrawn
No action
clanmills commented 2 years ago

Exiv2 v0.27.5 RC3 2021-09-30

Changes since RC2.

Group PR Topic Issue
Build #1938 Exiv2 v0.27.5 RC3 #1935
Lens #1936 Canon EF 80-200mm f/4.5-5.6 II #1906
Bug #1925 Fix out of range access in src/tags_int.cpp #1918
Bug #1924 Fix quadratic loops in pentaxmn_int.cpp #1910
Bug #1923 Remove bogus code in XMPUtils.cpp #1902
Build #1937 Fix compiler warning on Apple/M1/Clang https://github.com/Exiv2/exiv2/pull/1915#pullrequestreview-758174005
Build #1937 Fix linking libiconv on macOS with M1 Requires CMake 3.14+ #1903
Withdrawn Reading HEIC from iPhone images #1928

We intend to release Exiv2 v0.27.5 on 2021-10-22.

kevinbackhouse commented 2 years ago

Should we add "libFuzzer target (for improved security testing)" to the list of new features?

clanmills commented 2 years ago

Exiv2 v0.27.5 GM 2021-10-22

Topic More Info
Remaining ( 0) https://github.com/Exiv2/exiv2/milestone/9
Completed (87) https://github.com/Exiv2/exiv2/milestone/9?closed=1

Exiv2 v0.27.5 Features

  1. BMFF bug fixes including CR3 previews
  2. Security fixes
  3. libFuzzer target (for improved security testing)
  4. Exiv2 monitored by oss-fuzz
  5. Minor bugs and fixes

Exiv2 v0.27.5 Acknowledgements

This release is due to Kev and David, supported by the rest of the team. Thank You, Kev for your hard work and attention to detail. Thank You, David for your effort on CR3 Previews.

Contributor Activity
Alex Project Management
Christoph C++ code
David CR3 preview C++ code
Kev Outstanding work on security and other issues
Luis C++ modernisation
Miloš C++ code
Peter K C++ code
Peter S C++ code
Robin Release engineering

If I've forgotten to acknowledge your contribution, I apologise.

Help Wanted

Team Exiv2 is a happy band of enthusiastic engineers. We have several tasks for which we're looking for volunteers.

  1. Extended test coverage.
  2. Use of Coverity Scan (static code analysis).
  3. Release Engineer.

If you'd like to contribute to Exiv2, please talk to us on the chatserver: https://matrix.to/#/#exiv2-chat:matrix.org

What's next for Exiv2?

Team Exiv2 is very active and deals with several issues and PRs every week. There is no active release schedule at present. A reasonable guess about the future is:

  1. Probably another 0.27 dot release. Spring 2022 maybe.
  2. Exiv2 v1.00. Summer 2022 maybe.

Exiv2 v0.27.5 Release Notes (updated 2021-10-21)

Group PR Topic Issue
Bugs &
Fixes		 #1968 Canon cr3 previews #1893
#1981 Limit CR3 previews to JPEG only
#1975 BMFF Performance boost: don't read mdat box
#1925 Fix out of range access in src/tags_int.cpp #1918
#1924 Fix quadratic loops in pentaxmn_int.cpp #1909
#1923 Remove bogus code in XMPUtils.cpp #1901
#1889 Avoid reading 1 byte past end of no nul string #1888
#1884 Throw error if preview is greater than 1MB #1882
#1880 Add some XML validation to avoid xmpsdk bugs #1878
#1855 Enforce BMFF box nesting
#1848 Assert->error TiffDirectory::doWriteImage #1847
#1846 Assert->error TiffDirectory::writeDirEntry #1845
#1844 malloc->DataBuf WebPImage::decodeChunks #1841
#1840 Check float within int range before cast #1838
#1834 Assert->error TiffMnEntry::doCount() #1833
#1831 Safer cast double to long in value.hpp #1827
#1828 Check double in range before cast to uint32_t #1827
#1820 Check string isn't empty #1819
#1818 Fix memory leak in pngimage.cp #1817
#1816 check to prevent out-of-bounds read in memcmp #1815
#1814 jp2image.cpp: check size before allocation #1812
#1796 Check embedded RAF image is really a TIFF #1791
#1790 bufRead needs to be adjusted after seek()
#1789 &bytes[0] (std::vector) will crash if bytes has zero elements
#1788 Make sure that read is complete to prevent infinite loop
#1765 Add Exif.Image.PageName tag
#1758 Check iterator is not end() after findKey
#1752 Fix incorrect loop condition
#1745 avoid processing MOV files when BMFF enabled
#1739 Fix assertion failure in crwimage_int.cpp
#1737 Zero initialize local variables
#1735 Use vector::at() rather than operator[]
#1720 Stricter date parsing in value.cpp
Security #1882 Large allocation in tiffvisitor_int.cpp #1881
#1769 Safer std::vector indexing
#1778 Fix infinite loop Image::printIFDStructure
#1767 Extra checking to prevent loop counter from wrapping around
#1759 Better bounds checking in Jp2Image::printStructure
#1750 Avoid integer divide by zero
Lens #1936 Canon EF 80-200mm f/4.5-5.6 II #1906
Build #1983 Exiv2 v0.27.5
#1972 Only include expat.h when XMP is enabled. #1971
#1966 Fix macOS build failure
#1939 Add workaround for conan outage
#1938 Exiv2 v0.27.5 RC3 #1935
#1937 Fix compiler warning on Apple/M1/Clang https://github.com/Exiv2/exiv2/pull/1915#pullrequestreview-758174005
#1937 Fix linking libiconv on macOS with M1 Requires CMake 3.14+ #1903
#1897 Lock conan version on Windows
#1894 0.27.5 RC2 #1891
https://github.com/Exiv2/exiv2/commit/962ef361155880f02af519e05cc93ac7e7fbc7de builds fail on gitlab debian CI #1871
#1864 workaround for softprops/action-gh-release
#1862 Fix macOS workflow to use gtest 1.8.0
#1861 add doc to release builds
#1860 Exiv2 v0.27.5 RC1
#1859 Enable BMFF in Actions workflows
#1858 Fix compiler warning on Apple/M1/Clang #1856
#1854 Actions and fuzzer for 0.27-maintenance
Test #1853 Use @unittest.skip for ASAN builds #1821
#1754 Fix Ubuntu 20.04/Release/Sanitizer test breaker
XMPsdk #1851 memory leak in addBinding (xmlparse.c) #1821
Localisation
Documentation #1870 update_27.5_docs_again
#1868 update release notes for v0.27.5 RC1
#1865 update_docs_for_0.27.5.1
Withdrawn
No action		 improvable error message #1977
Crash in Debug Mode #1960
Reading HEIC from iPhone images #1928
include search path is wrong for exiv2 command-line program #1895
CI trigger #1873