ra...@siliconet.pl wrote:
>
>On 29.01.2025 4:16 PM, Roberto C. Sánchez wrote:
>> Yes, it still means that. The minizip binary package you are seeing
>> comes from a different source package, also called minizip:
>>
>> https://packages.debian.org/source/bookworm/minizip
>
>Aha! Got it :-)
>
>And th
On 29.01.2025 4:16 PM, Roberto C. Sánchez wrote:
Yes, it still means that. The minizip binary package you are seeing
comes from a different source package, also called minizip:
https://packages.debian.org/source/bookworm/minizip
Aha! Got it :-)
And there are no binary components in Debian b
On Wed, Jan 29, 2025 at 04:15:16PM +0100, Rafał Lichwała wrote:
>
>But still don;t understand "Debian itself does *not* build the affected
>component" as I can find "minizip" (and maybe other) package based on that
>vulnerable library - see my previous post above as Re- to Hanno.
>
Yo
On Wed, Jan 29, 2025 at 04:04:26PM +0100, Rafał Lichwała wrote:
>
> On 29.01.2025 3:35 PM, Hanno 'Rince' Wagner wrote:
> > > The notes say:
> > > [bookworm] - zlib (contrib/minizip not built and src:zlib not
> > > producing binary packages)
> > > In other words, there's no point in fixing it bec
On 29.01.2025 3:30 PM, Roberto C. Sánchez wrote:
On Wed, Jan 29, 2025 at 03:22:02PM +0100, Rafał Lichwała wrote:
On 29.01.2025 2:43 PM, Dan Ritter wrote:
CVSS are often bogus.
Hmmm... I'm not sure what you mean. All security announcements in DSAs are
referring to CVSS, so... what's
On 29.01.2025 3:35 PM, Hanno 'Rince' Wagner wrote:
The notes say:
[bookworm] - zlib (contrib/minizip not built and src:zlib not
producing binary packages)
In other words, there's no point in fixing it because Debian doesn't build the
vulnerable binary component.
Very low priority.
so, this
On Wed, Jan 29, 2025 at 03:22:02PM +0100, Rafał Lichwała wrote:
>On 29.01.2025 2:43 PM, Dan Ritter wrote:
>
> CVSS are often bogus.
>
> Hmmm... I'm not sure what you mean. All security announcements in DSAs are
> referring to CVSS, so... what's the source of such opinion?
>
>
> Most rec
On Wed, Jan 29, 2025 at 08:43:12AM -0500, Dan Ritter wrote:
>
> Most recently: https://daniel.haxx.se/blog/2025/01/23/cvss-is-dead-to-us/
I was going to post a link to this very article when I saw that you
already had :-)
Regards,
-Roberto
--
Roberto C. Sánchez
On 29.01.2025 2:43 PM, Dan Ritter wrote:
CVSS are often bogus.
Hmmm... I'm not sure what you mean. All security announcements in DSAs are
referring to CVSS, so... what's the source of such opinion?
Most recently:https://daniel.haxx.se/blog/2025/01/23/cvss-is-dead-to-us/
Yeah, another blog and
On 29.01.2025 2:39 PM, Hanno 'Rince' Wagner wrote:
How does your "automatically scanned for possible vulnerabilites"
actually work?
I don't know, but it does not matter in that context.
It does matter because you have to interpret the output of your
scanner and understand it.
Well, not really
Rafał Lichwała wrote:
>
> On 29.01.2025 2:12 PM, Dan Ritter wrote:
> > The notes say:
> >
> > [bookworm] - zlib (contrib/minizip not built and src:zlib not
> > producing binary packages)
> >
> > In other words, there's no point in fixing it because Debian
> > doesn't build the vulnerable bina
On 29.01.2025 1:57 PM, David wrote:
How does your "automatically scanned for possible vulnerabilites"
actually work?
I don't know, but it does not matter in that context. The fact is, that
the result of this "magic scan" properly found and points out the real
critical security vulnerabilitie
On 29.01.2025 2:12 PM, Dan Ritter wrote:
The notes say:
[bookworm] - zlib (contrib/minizip not built and src:zlib not
producing binary packages)
In other words, there's no point in fixing it because Debian
doesn't build the vulnerable binary component.
Very low priority.
Could you please
Rafał Lichwała wrote:
> Hi,
>
> I've prepared some docker image based on Debian 12 (bookworm, fully updated)
> and after upload it to local registry it has been automatically scanned for
> possible vulnerabilities.
> Then I was really surprised when discovered that according to this scan
> there
On Wed, 29 Jan 2025 at 12:40, Rafał Lichwała wrote:
> I've prepared some docker image based on Debian 12 (bookworm, fully
> updated) and after upload it to local registry it has been automatically
> scanned for possible vulnerabilities.
> Then I was really surprised when discovered that according
Hi,
I've prepared some docker image based on Debian 12 (bookworm, fully
updated) and after upload it to local registry it has been automatically
scanned for possible vulnerabilities.
Then I was really surprised when discovered that according to this scan
there are 139 security vulnerabilities
Hi.
On Sun, Apr 05, 2020 at 09:03:00PM +0100, Bhasker C V wrote:
> I kept digging down and saw that anything below 32 bytes is not accepted
> (by cryptsetup --key-file option) but anything above 32 bytes is
> discarded.
cryptsetup(8), "-s" option.
> Does this mean that cryptsetup plain
Hi,
Attached is something I found. I see that cryptsetup --key-file
arguement uses only first 32 bytes of the file and anything beyond is
unused.
I am on debian bullseye
$ cryptsetup --version
cryptsetup 2.3.0
$
Following is my test
$ cat b
#!/bin/bash
#create a file
dd if=/dev/zero of=./A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Kent West wrote:
> Probably not the best place to put this information, but I figure here
> is better than no where...
>
> I'm tinkering with authentication a Debian (10.1) box via Active
> Directory, so that an AD user can log into the Debian box.
On 11/8/19 11:53 AM, Roberto C. Sánchez wrote:
On Fri, Nov 08, 2019 at 11:36:34AM -0600, Kent West wrote:
Probably not the best place to put this information, but I figure here is
better than no where...
I'm tinkering with authentication a Debian (10.1) box via Active Directory,
so that an AD
On Fri, Nov 08, 2019 at 11:36:34AM -0600, Kent West wrote:
> Probably not the best place to put this information, but I figure here is
> better than no where...
>
> I'm tinkering with authentication a Debian (10.1) box via Active Directory,
> so that an AD user can log into the Debian box.
>
> Th
Probably not the best place to put this information, but I figure here
is better than no where...
I'm tinkering with authentication a Debian (10.1) box via Active
Directory, so that an AD user can log into the Debian box.
The relevant /etc/sssd/sssd.conf file has the following modification:
On 2010-03-09 21:46, Bret Busby wrote:
In running sybaptic, to check for available system updates, I
encountered the following message, and it is not the first time that I
have encountered the message.
"Granted permissions without asking for password
The '/usr/sbin/synaptic' program was started
On Tue, 9 Mar 2010 22:46:31 -0500 (EST), Bret Busby wrote:
>
> In running sybaptic, to check for available system updates, I
> encountered the following message, and it is not the first time that I
> have encountered the message.
>
> "Granted permissions without asking for password
>
> The '/u
>> The '/usr/sbin/synaptic' program was started with the privileges of the
>> root user without the need to ask for a password, due to your system's
>> authentication mechanism setup.
>> It is possible that you are being allowed to run specific programs as user
>> root without the need for a passw
Ron Johnson:
>>
>
> http://en.wikipedia.org/wiki/Hanlon%27s_razor
Completely unrelated to the OP, but the best extension to Hanlon's Razor
is given by the previous Friday's Dilbert:
http://dilbert.com/strips/comic/2010-03-05/
:)
J.
--
Ultimately, the Millenium Dome is a spectacular monument
On 2010-03-09 21:46, Bret Busby wrote:
Hello.
In running sybaptic, to check for available system updates, I
encountered the following message, and it is not the first time that I
have encountered the message.
"Granted permissions without asking for password
I think this is specific to this
Hello.
In running sybaptic, to check for available system updates, I
encountered the following message, and it is not the first time that I
have encountered the message.
"Granted permissions without asking for password
The '/usr/sbin/synaptic' program was started with the privileges of the
Hi,
Again a memory management problem, in mremap(). Affected 2.2.x,
-2.4.24, -2.6.2.
Original announcement:
http://isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt
Marcelo Tosatti's note:
http://marc.theaimsgroup.co
(Sorry for the cross-posting; this is somewhat important)
Versions 1.20-11.2 and 1.20-12 of wdm contain a configuration error that
caused X session authentication data to be stored in a non-existant
directory. In situations like this, the X server falls back to a
security mode which allows *all*
On Tue, Mar 06, 2001 at 10:55:40AM -0800, Ken Sandell wrote:
> Hey guys, I want to have User Read Only directories, but I want to have users
> in the same group and have them still not be able to read any other users
> home directories.
>
> Also, the folder ~user/web is where their web shit is a
Hey guys, I want to have User Read Only
directories, but I want to have users in the same group and have them still not
be able to read any other users home directories.
Also, the folder ~user/web is where their web shit
is and should be viewable.
> Hi,
>
> I have a question regarding security issue with Debian and Linux in
> general. By now everyone has probably heard about the new Mellissa
> virus. I know that this doesn't affect Linux because it is related to
> M$ products only. However, I just wondered i
In foo.debian-user, you wrote:
> I have a question regarding security issue with Debian and Linux in
> general. By now everyone has probably heard about the new Mellissa
> virus. I know that this doesn't affect Linux because it is related to
> M$ products only. However, I
Hi,
I have a question regarding security issue with Debian and Linux in
general. By now everyone has probably heard about the new Mellissa
virus. I know that this doesn't affect Linux because it is related to
M$ products only. However, I just wondered if anything of this sort
> As root, what if I want to keep a file in someones directory without them
> deleteing it ?
Using conventional Unix permissions, that is indeed the case. Note that
this so for all Unix-like systems, not just Linux. Root generally keeps
important files in root's own directories.
Using ACLs you mi
On Tue, 18 Mar 1997, Matthew Tebbens wrote:
>
> I'm not sure if this is normal, but it seems that any file owned by
> someone else and in one of my directories can be deleted by me even
> if I don't have the proper permissions to do so. I also can rename the
> file, but I can't alter the file. Th
Matthew Tebbens typed:
>
> I'm not sure if this is normal, but it seems that any file owned by
> someone else and in one of my directories can be deleted by me even
> if I don't have the proper permissions to do so. I also can rename the
> file, but I can't alter the file. This holds true even if
Philippe Troin very kindly remarked
>
> Permissions for removal/addition of files in a directory are controlled by
> the directory permissions, not the file permissions. Makes sense when
> said like this. Except_ for directories with the sticky bit set where
> only the owner of a file can remove i
If someone else owns the directory that the file is in, then they
basically own the file allocation table and can rename the file to
anything they want, or remove the filename alltogether. It's basically
like they own the filecabinet, and the other person's file is in the
cabinet. Even though the
FYI, your mailer is broken.
The headers mention calyx.net as a return address, but there's no
calyx.net domain around...
Well, actually, there's a Calyx.net domain in WHOIS, suspended
yesterday.
Say thank you to Internic, NSF and NSI !
I'm posting on debian user, in case this message doesn't arri
"David B. Teague" <[EMAIL PROTECTED]> writes:
>
> Matthew
>
> You could use chattr to make the file immutable. It is documented as
> chattr(1). Also see lsattr(1).
>
but keep in mind that it's an extension only valid for the ext2
filesystem.
Matthew Tebbens <[EMAIL PROTECTED]> writes:
>
>
> I'm not sure if this is normal, but it seems that any file owned by
> someone else and in one of my directories can be deleted by me even
> if I don't have the proper permissions to do so. I also can rename the
> file, but I can't alter the file.
Matthew,
> I'm not sure if this is normal, but it seems that any file owned by
> someone else and in one of my directories can be deleted by me ...
> I also can rename the file, but I can't alter the file. This holds true
> even if the file is owned by root.
>
> Is this normal ?
Yes. Pe
Matthew
You could use chattr to make the file immutable. It is documented as
chattr(1). Also see lsattr(1).
-- David
On Tue, 18 Mar 1997, Matthew Tebbens wrote:
>
> I'm not sure if this is normal, but it seems that any file owned by
> someone else and in one of my directories can be deleted by
On Tue, 18 Mar 1997 10:12:03 EST Matthew Tebbens ([EMAIL PROTECTED]
ishkill.ibm.com) wrote:
> I'm not sure if this is normal, but it seems that any file owned by
> someone else and in one of my directories can be deleted by me even
> if I don't have the proper permissions to do so. I also can ren
I'm not sure if this is normal, but it seems that any file owned by
someone else and in one of my directories can be deleted by me even
if I don't have the proper permissions to do so. I also can rename the
file, but I can't alter the file. This holds true even if the file
is owned by root.
Is th
47 matches
Mail list logo
