search for: reissuing

...raged to find out if there are patches which correct these problems before reenabling it on your system. The previous advisory suggested that any FreeBSD ports version of proftpd after August 30 had the security problems corrected. This has proven to not be the case and was the primary reason for reissuing this advisory. While reissuing the advisory, we added beroftpd since it shares a code history with wu-ftpd. The original advisory mistakenly asserted that proftpd also shared a code history with wuftpd, which is not the case. VI. Credits and Pointers The wu-ftpd advisory can be found at ftp:/...

-----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-00:61 Security Advisory FreeBSD, Inc. Topic: tcpdump contains remote vulnerabilities [REISSUED] Category: core Module: tcpdump Announced:

On Jan 3, 2011, at 11:30 PM, Jakob Stoklund Olesen wrote: > I noticed that we generate code like this for i386 PIC: > > calll L0$pb > L0$pb: > popl %eax > movl %eax, -24(%ebp) ## 4-byte Spill > > I worry that this defeats the return address prediction for returns in the function because calls and returns no longer are matched. Yes, this will defeat the

This problem is likely to be specific to Windows, and particularly Win7. After a successful build of a package (R CMD build addendum), I immediately run an R CMD check for the same package. Not always, but _very_ often, I get the following error: C:\Users\nisabbe\Documents\@Doctoraat\R>R CMD check addendum Loading required package: tcltk Loading Tcl/Tk interface ... done Loading

I noticed that we generate code like this for i386 PIC: calll L0$pb L0$pb: popl %eax movl %eax, -24(%ebp) ## 4-byte Spill I worry that this defeats the return address prediction for returns in the function because calls and returns no longer are matched. From Intel's Optimization Reference Manual: "The return address stack mechanism augments the static and dynamic

On Fri, Jan 07, 2011 at 02:22:51PM -0800, brianw at sounds.wa.com wrote: > > First of all, I am not aware of any official source of FLAC files > that provide MP3 sourced data. Unofficial sources (such as Usenet and that torrent site with the old fashioned sailing ship as its logo) are much more likely to have FLAC files that were made from lossy audio. And I vaguely remember reading

Lots of comments throughout this one... On Jan 7, 2011, at 15:28, Declan Kelly wrote: > On Fri, Jan 07, 2011 at 02:22:51PM -0800, brianw at sounds.wa.com wrote: >> However, you should be aware that many modern producers use software >> to create their music, and when the software stores sound clips in >> MP3 format, what you end up with is music that sometimes looks like

A hiccup was reported about validating the tarball signature on some systems, so it was reissued from another workstation. Please don't worry :) Jim Klimov On Tue, Apr 2, 2024, 01:06 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Hello all, > > After a prolonged labour with a few re-issues of the tag and many pushes > during the day, NUT v2.8.2 was found in a strange

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes: > A hiccup was reported about validating the tarball signature on some > systems, so it was reissued from another workstation. Please don't worry :) Do you mean the signature was re-issued, which is ok, or that the tarball was re-issued, which is very much not ok(!) ?

A hiccup was reported about validating the tarball signature on some systems, so it was reissued from another workstation. Please don't worry :) Jim Klimov On Tue, Apr 2, 2024, 01:06 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Hello all, > > After a prolonged labour with a few re-issues of the tag and many pushes > during the day, NUT v2.8.2 was found in a strange

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> writes: > A hiccup was reported about validating the tarball signature on some > systems, so it was reissued from another workstation. Please don't worry :) Do you mean the signature was re-issued, which is ok, or that the tarball was re-issued, which is very much not ok(!) ?

I have referred to the wiki and the RFC, but I still can't find the exact answer I'm looking for. From what I know, Dovecot uses the IMAP standard of 32 bit integers to uniquely identify messages. After a message is deleted from the mbox, can this UID ever be reissued to a new message or is that UID retired? What about after the 2 billion limit is reached? Thanks!

CentOS-2 update 5 is about to be released. As of update 5, Netscape 4.8 will be removed from the distribution. The currently shipped version of Netscape 4.8 has security flaws and should not be used. Users of CentOS-2 should uninstall the Netscape packages and switch to using mozilla. For more information see RHSA-2004:429-01 Also, in order to easily identify packages which have been

...ourier-imap we could just put every client certificate into a trusted cert file (or hashed directory for a larger number of clients) and courier-imap would check that through TLS_TRUSTCERTS. I would like to keep the current appproach and avoid the whole mini CA setup - that way I can also avoid reissuing new certs to all existing users. Question: can a similar setup be achieved with dovecot-imap ? I've already made numerous attempts with no luck. As far as I can see dovecot-imap does not seem to implement the concept of checking trusted (self signed standalone client) certs - even though i...

I need to disable the spin-down on an external USB drive because it spins down spontaneously while in use. The drive forgets the spindown-disable state across power outage so I need to reissue the hdparm command with each boot or hotplug. Where should I put the hdparm command to do this?

I'm receiving the following error over and over, adnauseam: Oct 1 23:59:53 NOTICE[3194]: chan_sip.c:5890 check_auth: stale nonce received from 'CNAME-CID <sip:5551212@192.168.1.X>' Does anyone know what "stale nonce" is? Thanks! Paul Conn -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, Just starting out with rsync, and I think I might be missing a fundamental point of how it works. Scenario: I start an rsync daemon on host A, and define a module 'test' on the rsyncd.conf file. 'test' is essentially my home directory on host A I then sign on to host B and issue rsync --progress --recursive --links --stats arthur::test/ /var/tmp/haggis This copies

Hi all. We developped a pv-scsi driver that we refered Fujita-san''s scsi-driver and blkback. (see, http://www.xensource.com/files/xensummit_4/Xen_Summit_8_Matsumoto.pdf) The pv-scsi driver''s feature is as follow: * Guest has dedicated SCSI-HBAs of Dom0. * Guest can send scsi_cdb to the HBAs. * Guest recognises the HBAs from hostno of xenstore. Currentlly, We are

...ExtractElements<2, i32>>, CCIfType<[i32], CCAssignToReg<[R0, R1]>> ]>; The problem is that i64 handling requires splitting into 2 x i32 registers. I am not sure how to build CCExtractElements as shown. The current organization of CCState::AnalyzeReturn does not allow for reissuing of the RET with an altered set of operands which is the solution used elsewhere. Can anyone suggest a better way to express this lowering? Deep On Fri, Dec 19, 2008 at 6:43 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > On Fri, Dec 19, 2008 at 4:54 PM, Evan Cheng <evan.cheng...

Hello, I use snapshot-create-as followed by blockpull when creating external snapshots of VMs. This works well, however I am curious about the behavior of blockpull after an unexpected shutdown (or SIGKILL). If a blockpull is in progress and an unexpected power loss occurs, will the VM continue to reference the backing file for the parts of it that have not yet been copied? Or, will will the disk