similar to: Security hole in Elm...

Displaying 20 results from an estimated 400 matches similar to: "Security hole in Elm..."

1998 Aug 22
0
Fwd: screen-3.7.4 (security update)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Date: Wed, 19 Aug 1998 23:30:58 +0200 (EEST) From: Marcin Bohosiewicz <marcus@venus.wis.pk.edu.pl> To: redhat-announce-list@redhat.com Subject: screen-3.7.4 (security update) Message-ID: <Pine.LNX.3.96.980819232924.15924A-100000@venus.wis.pk.edu.pl> I updated my package after BUGTRAQ fix for tmp-races in screen package. I built
1997 Apr 27
0
Overflow in xlock (fwd)
-| == Marcin Bohosiewicz marcus@venus.wis.pk.edu.pl == |- -| == tel. +048 (0-12) 37-44-99 marcus@krakow.linux.org.pl == |- -| == Strona Domowa - http://venus.wis.pk.edu.pl/marcus/ == |- ---------- Forwarded message ---------- Date: Sat, 26 Apr 1997 16:16:05 -0400 From: George Staikos <staikos@0WNED.ORG> Approved: R.E.Wolff@BitWizard.nl To: BUGTRAQ@NETSPACE.ORG Subject:
1997 May 15
1
Vulnerability in Elm-ME+
Hello, I have confirmed that the recently-reported vulnerability in Elm is also present in Elm-ME+ and thus also in Debian GNU/Linux version 1.2, prerelease version 1.3, and development tree "unstable". Below is a short diff to correct the problem. Debian GNU/Linux 1.2.x uses stock Elm 2.4pl25. Users of that version of Elm should upgrade to Elm-ME+ as detailed below. Debian 1.3
1997 May 29
1
Vulnerability of suid/sgid programs using libXt
-----BEGIN PGP SIGNED MESSAGE----- Buffer overflow in the resource handling code of the libXt (X11R6) Thu May 29, 1997 Distribution of this document is unlimited Copyright (C) Alexander O. Yuriev (alex@yuriev.com) Net Access Abstract A buffer overflow was found in the resource handling
1997 May 14
4
cxterm buffer overrun
cxterm is a Chinese terminal emulator for the X Window System. It''s installed as suid-root by default if you did a make install. Just like xterm, it does needs to be suid to update /etc/utmp...blahblah... I discovered some buffer overflow bugs in it. The code attached below is the exploit. Quick fix? chmod -s /path/cxterm
2005 Aug 23
0
CESA-2005:755-01: Critical CentOS 2 i386 elm security update
The following errata for CentOS-2 have been built and uploaded to the centos mirror: RHSA-2005:755-01 Critical: elm security update Files available: elm-2.5.6-6.i386.rpm More details are available from the RedHat web site at https://rhn.redhat.com/errata/rh21as-errata.html The easy way to make sure you are up to date with all the latest patches is to run: # yum update -- John Newbigin
2013 Feb 18
2
[LLVMdev] Pointer Context Metadata (was: Parallel Loop Metadata)
On 02/17/2013 11:15 PM, Hal Finkel wrote: > If the unroller somehow differentiates the metadata coming from different > loop iterations, then BBVectorize can use this information as well. Even > better, we could make BasicAA understand that appropriately marked loads > and stores from different iterations don't alias. Then the AA-based > dependency breaker in the scheduler could
2013 Feb 18
0
[LLVMdev] Pointer Context Metadata (was: Parallel Loop Metadata)
----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Andrew Trick" <atrick at apple.com>, "Tobias Grosser" <tobias at grosser.es>, "llvmdev at cs.uiuc.edu Dev" > <llvmdev at cs.uiuc.edu> > Sent: Monday, February 18, 2013
2015 Jul 07
2
[LLVMdev] SPMD Autovectorizer
On 07/07/2015 01:32 PM, Renato Golin wrote: > Wouldn't OpenMP account for some of that? At least on a single > machine, could you have both parallel and simd optimisations done on > the same loop? The point in SPMD program description (e.g. CUDA or OpenCL C) autovectorization is to produce something like OpenMP parallel loops or SIMD pragmas automatically from the single thread/WI
2007 Jan 18
1
Robust PCA?
Hi. I'm checking into robust methods for principal components analysis. There seem to be several floating around. I'm currently focusing my attention on a method of Hubert, Rousseeuw, and Vanden Branden (http://wis.kuleuven.be/stat/Papers/robpca.pdf) mainly because I'm familiar with other work by Rousseeuw and Hubert in robust methodologies. Of course, I'd like to obtain
2023 Nov 22
1
mediaplayer for icecast streams?
Icecast provides an endpoint (/status-json.xsl) which returns JSON with various data, including "Now Playing". Here is a link to the documentation: https://www.icecast.org/docs/icecast-trunk/server_stats/ In your case it looks like it would be http://radio.protestbandet.dk:8000/status-json.xsl Ben Weddle -----Original Message----- From: Icecast <icecast-bounces at xiph.org> On
2019 Nov 19
2
Fwd: RFC: Moving toward Discord and Discourse for LLVM's discussions
On 11/19/19 9:09 AM, Zachary Turner via llvm-dev wrote: Note there is also Slack, which does not have these problems. Not sure why that keeps being overlooked My understanding is this is because Slack does not have good moderation tools. I'm unfamiliar with further details in this regard. -Hal On Tue, Nov 19, 2019 at 7:07 AM Zachary Turner <zturner at roblox.com<mailto:zturner at
2004 Jul 15
2
Samba LDAP Problem
Dear Lists, I try to configure Samba as PDC LDAP backend with Linux-Suse-9.1 and smbldap-tools form www.idealx.org, I follow guide from SMB-3 by Example book. Step by step installation and configuration came with no error. except i couldnt join w2k workstation to the new domain with administrator account. # /var/lib/samba/sbin/smbldap-usershow administrator dn:
2019 Nov 19
3
Fwd: RFC: Moving toward Discord and Discourse for LLVM's discussions
But is it better or worse than IRC in this regard? On Mon, Nov 18, 2019 at 10:49 PM Daniel Chapiesky via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > ---------- Forwarded message --------- > From: Daniel Chapiesky <dchapiesky2 at gmail.com> > Date: Tue, Nov 19, 2019 at 1:48 AM > Subject: Re: [llvm-dev] RFC: Moving toward Discord and Discourse for >
2014 Nov 21
4
[Bug 10951] New: Emtpy parameter triggers unwanted behavior, but no error message
https://bugzilla.samba.org/show_bug.cgi?id=10951 Bug ID: 10951 Summary: Emtpy parameter triggers unwanted behavior, but no error message Product: rsync Version: 3.1.0 Hardware: x64 OS: Linux Status: NEW Severity: major Priority: P5 Component: core Assignee:
2020 Aug 24
2
ORC JIT - Incorrect support for COFF files?
Hey Lang and Stefan, Using dllimport on my “planschiValue” actually worked! But I have no idea why, because the relocation is still a REL32 if I use dumpbin… So how is it possible for that to work? However… when I load an COFF object file, am I able to change the relocations to dllimport somehow? I honestly can’t imagine how this would work since the machine code is probably already adjusted to
2012 Feb 24
0
winevdm.exe error
When attempting load a computer based auto repair manual program "SAAB WIS (Workstation Interface System)", which will only run under Windows 32bit and lower OS, I get the following error about half way through the installation process: Program Error: The program 'winevdm.exe' has encountered a serious problem and needs to close. What can I do to help remedy the problem?
2023 Nov 22
1
mediaplayer for icecast streams?
Thank you, Ben! I was afraid it would be very complicated to get the information extracted, but it was very simple. My only problem now is to find a way to update the text on the webpage. I was hoping sleep(5) could do the trick, but it does not work. <?php if (1) { $jsonobj=file("http://radio.protestbandet.dk:8000/status-json.xsl"); //var_dump($jsonobj);
2015 Sep 14
1
xapian-core-1.2.21 ported to Interix / 'gmake check' compile error
Report by Eric Lindblad 13-09-2015 http://www.ericlindblad.blogspot.com cf: http://comments.gmane.org/gmane.comp.search.xapian.general/9862 I ported xapian-core-1.2.21 to Interix today having disabled the default chert and development brass backends, using flint, which was the 1.0.x series' default, which ships with the 1.2.x series; the disabling do to an unresolved 'ambiguous
2011 Dec 14
2
[LLVMdev] Changes to the PTX calling conventions
Hi all, On 12/13/2011 10:50 PM, Justin Holewinski wrote: > You mean having no calling convention for device functions, and a new, common > calling convention for kernels? I think this might make sense. One major issue with OpenCL C (and I suppose CUDA) kernels some fail to see is that the functions are "directly callable" (just by choosing a correct the calling convention) in