Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it

2020-12-03 Thread Rogério Theodoro de Brito
First of all, thank you for including me on replies.

Regarding the subject, I think that the best way to proceed would be to, 
essentially, create a task force to maintain chromium properly.

I don't think that I have the computational means to compile chromium 
frequently (I hope that using ccache and/or distcc can be used), but I may be 
interested in, participating in the effort.

That being said, I think that inviting other people would be the way to go, 
including the maintainers from Linux Mint, and other distributions. There are 
other people maintaining chromium forks out there, IIRC, like a project called 
de-googled chromium, or something like that.

Inviting all those people in a task force and working openly (and with 
redundant human resources) is, IMVHO, something desired, not only for chromium, 
but for other software.

Since you mentioned armhf, Riku, we may try to get people from raspbian and 
other downstreams to also take part.

Also, given enough hands, splitting components/vendored libraries that chromium 
quite possibly includes (like the last time that I checked) could be something 
desired for, say, security purposes and, also, for other teams (IIRC, there is 
a bunch of multimedia libraries that were vendored).

(Of course, the "de-vendoring" should occur only when feasible).

That is my vision of how the packaging could go forward.

Thanks,

Rogério Brito.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Bug#436159: Serious indexing problems in fsck_hfs

2007-08-08 Thread Rogério Theodoro de Brito

Dear Darwin Develpers,

I am a Debian user and prospective Debian Developer that has packaged  
the disk utilities of Darwin for Debian and I noticed a pretty  
serious problem when compiling the fsck_hfs utility under many 64 bit  
platforms.


The bug manifests itself as a segmentation fault when running such  
fsck on, for example, a disk image created by newfs_hfs.


I traced the problem in a 64 bit platform to be a quite silly problem  
that is present in MacOS X 10.4 from releases 10.4.5 up to 10.5.9,  
which is the last available version on the Open Source site that  
Apple maintains (unfortunately, it doesn't have the sources for  
10.4.10, which is quite needed here).


The problem I'm referring to is in the fsck_hfs.tproj/dfalib/ 
hfs_endian.c file and it has the following snippet (sorry for the  
line-wrapping, but I don't know how to avoid that with Mail.app,  
which is what I am using right now):


(Around line 519):
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
for (i = 0; i < srcDesc->numRecords; i++) {
	/* Point to the start of the record we're currently  
checking. */
srcKey = (HFSPlusCatalogKey *)((char *)src->buffer +  
srcOffs[i]);


/*
 * Point to start of next (larger offset) record.  We'll  
use this
 * to be sure the current record doesn't overflow into  
the next

 * record.
 */
nextRecord = (char *)src->buffer + srcOffs[i-1];

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The code above was taken from the package diskdev_cmds-332.22.tar.gz,  
which is the last one available for download at the Apple site.



Please, notice that when i = 0, the last line quoted has srcOffs 
[i-1], which tries to access the position of index -1, which is  
obviously an error as it is not protected by an if or something similar.


Unfortunately, almost the same piece of code is repeated quite often  
in such file (I counted the repetition of this line at least 6 times  
in that file, which is, obviously, really not desired). I believe  
that some of the repetitions could be addressed with a cleanup.


Oh, BTW, if I am not mistaken, the code in this module (not limited  
to this file) also has some unfortunate assumptions of the size of a  
pointer being the same of an unsigned integer, something which is  
false in some (or maybe all) 64-bit architectures.


I'm carbon copying the Gentoo Developer of the same package, the bug  
sumitter to the Debian Bugtracking System, some friends of mine and  
another kind Debian Developer as well as the security contact that I  
could find on the page .


Just a small point here regarding the Apple mailing lists, I tried up  
to now 4 times to subscribe to Apple mailing lists without success to  
inform you of such serious problems. I hope that this time this e- 
mail won't bounce back to me (which would be a sad state of affairs,  
since I am trying to help with your products and this is the very  
soul of Free Software).


If I don't hear back or if this mail bounces, I am afraid that I will  
be quite sad with the position that Apple has chosen to adopt. After  
all, all I am trying to do is to point out grave problems that should  
be addressed quite soon, as the users relying on fsck_hfs to repair  
their possibly damaged fileystems may be in a high danger.



Regards, Prof. Rogério Brito.

--
Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org