search for: allege

[redirected from -hackers to -security] Jakub Lach <jakub_lach@mailplus.pl> writes: > http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html DES -- Dag-Erling Sm?rgrav - des@des.no

Hi all, Several people have written to me over the past couple of days to ask about a youtube video which allegedly shows a local root vulnerability in 8.1-beta1 being exploited. It is possible that the video is real and someone has found a vulnerability. It is also possible that the video is completely fake. There is no evidence on the video which is remotely conclusive in either direction. Given that th...

Hi,There is an alleged OpenSSH vulnerability, see http://www.cpni.gov.uk/Products/alerts/3718.aspx.According to this vulnerability an attacker can potentially recover 32 bits of plaintext from an arbitrary block of ciphertext. After having read the vulnerability note in more detail, my understanding is that the 32 bits...

...berry" <tterribe at xiph.org<mailto:tterribe at xiph.org>> Cc: "opus at xiph.org<mailto:opus at xiph.org>" <opus at xiph.org<mailto:opus at xiph.org>>, Marcello Caramma <mcaramma at cisco.com<mailto:mcaramma at cisco.com>> Subject: Re: [opus] Alleged bug in Silk codec Yes those instructions exist, although they're a bit slower than the basic 16x16->32 with 32-bit accumulation (SMLABB). So I'd be surprised if the function with 64 bit accumulation would run as fast as the current code. Don't know how much we care about 16-bit p...

Hi Marcello, Thanks for the report. It's hard to debug this without the actual file. Can you please post the sweep_in.raw file you used? Cheers, Jean-Marc On 11/06/14 04:46 AM, Marcello Caramma (mcaramma) wrote: > Hi, > > Apologies if this is a known issues, but I have found what I believe is > a bug in the fixed point implementation of the Silk codec and could not > find

KOEN VOS wrote: > current implementation is faster on a 32 or 16 bit processor. If you > would find the opposite to be true (ie that a 64 bit implementation is > faster on, say, a 32 bit ARM CPU) then perhaps we should reconsider. Doesn't ARMv6 have a dual signed 16x16->32 multiply with a 64-bit accumulator (SMLALD)? Even v5E should have a single 16x16->32 with a 64-bit

Hi Marcello, Thanks for the info and the proposed fixes. I'm currently investigating what's going on here before deciding on the best way to fix the problem. Have you been able to figure out why it doesn't work for rshifts >= 3? Cheers, Jean-Marc On 13/06/14 12:28 PM, Marcello Caramma (mcaramma) wrote: > Hi Jean Marc, > > please find attached the audio file (mono

Hi Marcello, It turns out that the problem has a much simpler explanation. As far as I can tell, it's actually a bug in silk_sum_sqr_shift() and this trivial patch appears to fix the problem: http://jmvalin.ca/misc_stuff/sum_sqr_shift_fix.patch It would still require some testing to check that the fix doesn't have any bad side effect. Let me know how well the fix works for you. Again,

Yes those instructions exist, although they're a bit slower than the basic 16x16->32 with 32-bit accumulation (SMLABB). So I'd be surprised if the function with 64 bit accumulation would run as fast as the current code. Don't know how much we care about 16-bit platforms. And accuracy should not matter. On the other hand, a 64-bit implementation is much cleaner/shorter, which is

I searched but was unable to locate a close match for this case. I doubt that Samba was the culprit here, but unus vir nullus vir. Your feedback would be appreciated. Situation: Windows clients, mostly WinXP desktops, got "no logon servers are available" when trying to access shared directories on fileservers. The Windows domain controllers run Win2k3. Member servers range from

Some of you probably already read this: http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 Interesting...I wonder what is the impact of all this on FreeBSD code. We may very well suppose that any government or corporation funded code can theoretically have some kind of backdoor inside. --Andy

The windose application I am trying to run bombs with the following error box. unknown has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. OK I can't find the alleged "error log." Any ideas where it may be? Thanks, SJr

I need to write a win32 program. However, my workstation is a Linux box. I was goingto create a cross compiler and compile my code and run it on wine... However, I heard about winelib, and allegedly I can just use winelib and compile on my linux box using good ol' gcc and it will just work. Is this true? If so how would I set that up? Where can I find the docs?

Hi Marcello, Actually, we were careful to avoid the undefined behaviour here. In fact, we are specifically running a clang test detecting undefined behaviour. If you look at the silk_SMLABB_ovflw() macro, you will see it is based on silk_ADD32_ovflw(), which is defined as: #define silk_ADD32_ovflw(a, b) ((opus_int32)((opus_uint32)(a) + (opus_uint32)(b))) By casting to unsigned, all the cases

Yes, I am a newbie at R, but it is not the complex commands in R that have me baffled, but simple data commands. For example, why does something like: > plot(Girth ~ Height) *not* work after a command that allegedly loads the data: > data(trees) with the error message: Error in eval(expr, envir, enclos) : Object "Girth" not found but does work after the command: > attach(trees) ? - JRV -- There are 10 kinds of people: those who understand binary, and those who don't

Dear list I have a vector of values that allegedly have a chi-squared distribution. I want to create a plot that shows the values I have obtained, and the chi-squared distribution curve for the specified number of degrees of freedom to show what should have been obtained. At the moment I am plotting the values I have obtained as a histogram...

Hi, Apologies if this is a known issues, but I have found what I believe is a bug in the fixed point implementation of the Silk codec and could not find any mention on this in the archives. The bug can be easily reproduced with the fixed point demo program (./configure ?enable-fixed-point ?disable-float-api && make) using the following command: ./opus_demo voip 16000 1 23000

...firmation, the is quite terse: "Allow use of key foobar? Key fingerprint abcdf." It would be desirable to have instead a text like: Confirmation is required before allowing usage of key foobar Key fingerprint abcdf. to process 1234 (ssh example.com rsync --server --sender -logDtpre.iLsf) allegedly for "connecting to example.com (1.2.3.4)" The rsync command line would be recovered by the agent itself, thus being quite trustworthy. In this case the example represented a local application. If it was a forwarded request it could be: Confirmation is required before allowing usage...

...the source hard drive > into the destination machine and use rsync to copy it from one drive to > the other (rather than using rsync to copy from one machine to the other > over the network). Why? I just rsync'd 159G in less than one workday from one server to another. Admittedly, we allegedly have a 1G network, but.... mark

...we already do for lld. We collect and order file (run a >>> profiler) and pass that to the linker that lays out functions >>> accordingly. >>> This is to improve startup time for a class of startup-time-sensitive >>> operations. The algorithm proposed by Pettis (allegedly) aims to >>> reduce the TLB misses as it tries to lay out hot functions (or >>> functions that are likely to be called together near in the final >>> binary). >>> >> >> IIRC from when I looked at the paper a while ago, it is mostly just a >>...