Replies: 10 comments 21 replies
-
|
I also immediately thought of openPDF when I read about the XZ incident. The repercussions of this incident can have quite some impact on the open source community. The criteria how to become a maintainer should be really carefully considered.
I am using openPDF (or still my own iText fork which I am in the process of migrating).
Sure
I am an active Member I would say but I fear I don't have the time to fill an admin role...
Sure, already did in the past
Sure, already did in the past I also thought of @mkl-public which is a valuable member of the PDF community and iText and has great insight in many aspects of the standard. He did also contribute a lot. He is involved in at least 90% of all questions on Stackoverflow for PDF and signing :-) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much. OpenPDF won't be here without the many contributors like you. This is a crucial part of the development of the library. |
Beta Was this translation helpful? Give feedback.
-
|
I've been a committer because my iText fork was the base used at the start of OpenPDF. All the work done on iText/OpenPDF was for my work duties at Tizra, where I am a founder. I think my fork was used mostly due to my having rounded up most other forks' patches at the time it started, and because I actively committed some work on text extraction, which I modified for Tizra's convenience, and in which I fixed many bugs. As to using OpenPDF: I continued for some years using my own fork, as most of the new features in the main project are related to PDF generation; Tizra uses iText only for full-text extraction and document excerpting and reassembly. However, Tizra recently started using the released versions of OpenPDF, since it's fixed some bugs that were causing trouble. Unfortunately, being CTO of a small company does not really leave me time for administration on a project that is basically a stable part of Tizra, but not a place where we need to make advancements. I think my path to being a committer for the project makes me a low security risk. While I can try to to make some more efforts for review of pull requests, I can't be an active admin. I would be a little sad not to be a committer, but I would understand if you feel that should change as a matter of policy. I am not opposed to receiving direct email from the group if my assistance would be useful, and in fact direct email might help to get my attention, as I don't pay regular attention to the commit logs. I am willing to participate in discussions and I will continue to be a user of the project, so I do care about its future. |
Beta Was this translation helpful? Give feedback.
-
|
I understand you points. Time is the real resource we all lack. In different scales, of course. Seeing you the the discussions would be very nice. |
Beta Was this translation helpful? Give feedback.
-
We are a heavy user of OpenPDF, both directly and via Flying Saucer. As such, we do care about the library.
From what I can remember I got the role after asking the previous owner about helping maintain the library. If I remember correctly the initial reason for the contact was a bug that we wanted to get fixed. As for now I think the best is that I keep the role as a backup until we find someone that got the time for it. One possible option would be my colleague @andreasrosdal , but I would have to ask him about it first.
I used to several years ago, back when I worked on the team that used this library, my colleague @andreasrosdal still works on that team. In regards to helping out more that is something I should do more as I should have a bit more time available this year, but no guarantee.
As in how the process works currently or what would be optimal? Personally as long as all changes are properly reviewed and version set properly the rest of the process should be automated. The main reason is that avoiding the need for having credentials locally on developer computers and avoiding having a developers computer being part of the deployment process should be safer and more practical in the long run. |
Beta Was this translation helpful? Give feedback.
-
|
I wouldn't retire from the project, but having another one to review and merge PRs is really a nice help. I had some difficulties releasing often in the past, because I wanted to keep the list of contributors up to date, and create nice ChangeLogs manually. I just gave up on that, and use the functions from GitHub. This should be enough. The aspect about not building on the developer's machine is a good point. I created a script to automate the steps. It is less error prone, but don't work 100% all the time. Nexus-Release got a timeout, and I must resume from that point. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Yes, I think it is evolving this way already. And I'll try to be really critical in PRs. Another point I'll try to do is triage the Issues better, closing issues which are too old (an no discussion was triggered). As for me, I also use OpenPDF in the company, which was using the deprecated iText. The upgrade was easy with only some minor changes required. That's why I maintain it. But I see myself much more as a "project manager" here, as I'm no PDF-pro. So my focus will stay on code quality and maybe automation. |
Beta Was this translation helpful? Give feedback.
-
|
I've been unable to contribute to the project for many years now. I'm so happy to see the progress that has been made and all of the awesome contributors. I now work for a company that builds PDF tools and I likely should not be a part of this project any longer (I'm worried about the conflict of interest). Please revoke any of my rights. I will keep an eye on the project and I hope for nothing but the best for it going forward! |
Beta Was this translation helpful? Give feedback.
-
|
@rtfarte Ok, I'll give you only read access. Or if you really want remove at all. |
Beta Was this translation helpful? Give feedback.
-
|
Read access sounds great. Thanks, again! |
Beta Was this translation helpful? Give feedback.
-
|
Just removed you as a member, and invited as a Reader. I'm not sure you really need this (technically) but this way you are listed in the project ;-) |
Beta Was this translation helpful? Give feedback.
-
My main employer uses OpenPDF in two older products. But these products are currently being phased out.
I'm interested in open source PDF libraries in general and, therefore, also in OpenPDF.
I'm part-time working as freelancer for iText (now Apryse). Thus, there may potentially be a conflict of interests here. @Lonzak thanks for your recommendation nonetheless.
Due to the potential conflict of interests I would prefer to limit myself to reviewing and discussing but not merging or releasing. I.e. just like now ;) |
Beta Was this translation helpful? Give feedback.
-
|
Andreas Røsdal commented (and meanwhile has deleted his comment):
Code contributions by nobody should be trusted without serious review. Singling people out in this regard looks like a sign of not taking the security regards discussed here seriously. |
Beta Was this translation helpful? Give feedback.
-
|
Update - for future reference: The author has deleted his comment so I hope we can continue to put our efforts into openPDF and not waste our time with unhelpful discussions. Previous answer: Regarding the remarks about mkl I strongly disagree. He freely explained why he can not take a more prominent role which was honest and understandable. But now to "encourage" (what a bad use of the word in that context) mkl to completely stay away from the project would be, to put it mildly a bad idea. His deep knowledge of the PDF standard and openPDF / itext as well as other pdf libraries is highly valuable and so are his code contributions / reviews and so on. He has probably answered most questions on stackoverflow regarding PDF and PDF open source libraries including openPDF. Writing something like this shows great disrespect of the voluntary contributions and the time invested here and leaves me puzzled why somebody would even suggest that. |
Beta Was this translation helpful? Give feedback.
-
|
Update: The author has removed his comments so I hope we can continue to put our efforts into openPDF and not waste our time here. Previous answer:
This is the answer:
|
Beta Was this translation helpful? Give feedback.
-
|
I hate any kind ot finger pointing. |
Beta Was this translation helpful? Give feedback.
-
|
Some thoughts about this discussion so far. Real namesMany files are updated to ask contributors to use a real name. It may be nice to have real names of contributors, but there is actually no way to check if the given real name is really a real name. "Jia Tan" sounds like a real name, but it isn't. Or it is a real name, but not a real person. I'm also a big fan of privacy, so actually I don't care if someone is using their real name in GitHub (but I appreciate that "git" itself is configured with a real name and e-mail from the contributors). PR qualityAs a maintainer I must have some kind of quality gate for the PRs. In the past I avoided rejecting PRs, but it is important to maintain the quality (sic) of the code (or increase it). So I'm changing to reject really bad PRs. I expect that the code must compile, the tests should pass and no checkstyle errors arise. I would appreciate that new tests are added. And even if there are many good senior contributors, other PRs are just simple and written by beginners. I can't block these kind of PRs, as this doesn't motivate new contributors with less coding experience. So if the code compiles and respect the above criteria, it's ok to consider merging it. The PR must be reviewed anyway, and if something is not nice or fishy, I must be pointed too. Conflict of interestIt's important that people with conflict of interest keep their distance. For me this means they should not controbute with code, as the above cases (you are working at/for iText or any company which may see OpenPDF as a concurrent). So I understand why the people would avoid not only contribute with code, but being a maintainer with Merge rights and the like. But I don't think it is a problem if these people contribute in other ways, as participating in discussion, answering questions, pointing security problems or helping understand any issue. My take-aways till nowI was wanting to make a "call for maintainer", where people could express their interrest in helping out with merging PRs, managing issues and discussions. That is not the case anymore. OpenPDF will be maintained as it is. No changes will occur (for now). If you maintained the project before (in contrast to "just" contributing), and want to help out now and then with some management task, I'll be glad to have you back. In the case nobody have time for that, I would cherry pick some contributor with a relevant amount of PRs, with good code guides. And if the person accepts, I would try to find a way to check, that the person is real. |
Beta Was this translation helpful? Give feedback.
-
|
I recommend to study the XZ Utils backdoor case, in order to prevent this from occuring again in an open source project. https://en.m.wikipedia.org/wiki/XZ_Utils_backdoor https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 Based on this I would suggest to be very strict in accepting code from people on GitHub. I think it's important to know who the people we are dealing with actually are. So the security of the OpenPDF source code should be more important than the code contributors wish for anonymity. The existing source code should get more scrutiny and review for finding security vulnerabilities. OpenPDF works correctly today, so there is no urgency for accepting changes from random people on the Internet. |
Beta Was this translation helpful? Give feedback.
-
Why "from people on GitHub"? Why not simply
instead? Do you have other, more secure ways of code inflow on your mind?
But how will you be sure? Even if the person somehow identified to the LibrePDF team (e.g. by postident or videoident), how do you know their github access hasn't been hacked? IMO a serious review by people who have an idea of the impact of the code changes in question is the more viable approach to focus on.
How can you be so sure? (Admittedly, I also do assume that OpenPdf itself does not contain any own backdoors by now. But I also know this merely to be an assumption. And, furthermore, there is quite a number of dependencies I have not really looked into yet. Also I am not aware of any OpenPDF code that explicitly counters malicious PDF structures, so I think that it's safe to assume that OpenPDF is vulnerable at least to DOS attacks, e.g. by ZIP-bomb-like streams...) |
Beta Was this translation helpful? Give feedback.
-
|
While a real name policy on first glance might sound like a good idea, it has several draw backs (some of which have been already mentioned here).
So I would suggest:
|
Beta Was this translation helpful? Give feedback.
-
|
But who is andreasrosdal? Might be a real name or a hacker impersonating andreasrosdal. So if I am a malicious actor I just need to a pick a name which sounds like a real name? Easy. This doesn't prevent anything except you have some real verification backing this up, like an eID or video identification. But who pays for that? Maybe this should be the task of github to offer something like this (verified accounts) but this is a completely different topic... |
Beta Was this translation helpful? Give feedback.
-
|
The new real name policy requirement means that all future pull requests from anonymous users, such as yourself, will be denied. This new policy will make OpenPDF more secure, and it will reduce the maintenance effort, because there will be no pull requests from anonymous users to review. See: https://github.com/LibrePDF/OpenPDF/blob/master/CONTRIBUTING.md |
Beta Was this translation helpful? Give feedback.
-
No it won't. Why should it? |
Beta Was this translation helpful? Give feedback.
-
|
The new policy is more secure, because from now on code contributions from anonymous people, who we have no idea who are, will be rejected. When someone is an employee in a company, the identity of the employee is always verified. The same principle applies here. Lonzak, you can see yourself out and go home now. |
Beta Was this translation helpful? Give feedback.
-
The same rule applies to you. Who is andreasrosdal? How does your gmail address provide any trust?
Sure, and now you're being offensive again when you run out of arguments. You seem to have problems when people disagree with you or have a different opinion. It's not acceptable to get personal or lose respect just because you disagree. You must learn to remain professional and handle disagreements constructively. Let's try to continue discussing on a factual level without undermining the culture of the conversation. |
Beta Was this translation helpful? Give feedback.
-
|
Who is Andreasrosdal ? - person I trust, period.
Both can be solved by combining detailed code review together with non anonymous policy. kulatamicuda ( round ball in my Czech language) |
Beta Was this translation helpful? Give feedback.
-
I am glad to be notified what is happening with it.
Yes in small hobby projects but we plan to have some bigger real project based on it in 2025. All will depend on maturity of OpenPDF.
I am very busy.
It depends on you. If possible keep my current status. If not, I will not cry.
Not now unfortunately, maybe in 2025 if we decided to use OpenPDF in real customer project.
Will try from now on.
From my experience two releases per year is enough. We should focus on stability, security and backward compatibility.
Ask AndreasRosdal if he want to, but still do code reviews ( we do not want repeat xz) Best regards and thank you again for the amazing work! |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
NetBSD bans all commits of AI-generated code: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi there,
I'm just wanting to reach out (ping) for everyone who still have some privileged permissions on OpenPDF. I was unsure in how I should do this, as there is not really a communication channel for a closed group of people in GitHub, and I didn't want to write you an "invasive" E-Mail out of nowhere. I hope you are all well and healthy.
The fact of the "XZ-Tools Backdoor" made me think a lot about FOSS and OpenPDF in the last days. How to make sure that OpenPDF will continue to be maintained and released.
OpenPDF has 3 Admins (or LibrePDF owners)
And another 3 Members (in my point of view all inactive):
And a very active (now non-privileged) community member: @andreasrosdal
My hope is you will get notified of this OpenPDF thread by GitHub. And if that reached you, you may reply here in GitHub or drop me an E-Mail (from the log of git, it's a valid one. Preferred way).
Just let me know some things:
As you may guess, I'm interested in finding another maintainer (or 2) to help me with all these management tasks, as I'm not always that available.
So I thought about an strategy in finding candidates I can contact. You are my first choice, because of obvious reasons. In the case you don't want to be active (which is fine, your decision), I would then search in the git-history for contributors with relevant commits or a relevant amount of commits. Maybe I'll look at other metrics, like changed lines, or the like.
Another source of wisdom may be the people participating in the issues, commenting and explaining things. I must see how this could be automated (find the user with most comments in the issues, or the one participating in more different issues).
And than there is the point where I want to be sure, that the chosen one is a real person and a "good guy". I'm still thinking about how I'll do that.
Thank you all for the work you've done in OpenPDF. I'm interested in your feedback (as a comment or e-mail).
If you were not mentioned in this discussion, just register that it care about the future of OpenPDF.
Beta Was this translation helpful? Give feedback.
All reactions