Git: Git-2.24.1.2-64-bit.exe installation and security vulnerabilities

[dlk-pavan]

As per the updated version of Git-2.24.1.2-64-bit.exe provided as per issues#2427, our security team has issued attached vulnerabilities report. Please help to resolve the vulnerabilities and also suggest how to eliminate these issues
git-22412-64-bitexe-2020-01-03-042152.pdf
git-22412-64-bitexe-components.xlsx

or any alternatives available.

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

```Git-2.24.1.2-64-bit.exe
$ git --version --build-options

* insert your machine's response here *

 - Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

* insert your machine's response here *

 - What options did you set as part of the installation? Or did you choose the
   defaults?

One of the following:

type "C:\Program Files\Git\etc\install-options.txt"
type "C:\Program Files (x86)\Git\etc\install-options.txt"
type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

* insert your machine's response here *

 - Any other interesting things about your environment that might be related
   to the issue you're seeing?

** insert your response here **

### Details

 - Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

** insert your response here **

 - What commands did you run to trigger this issue? If you can provide a
   [Minimal, Complete, and Verifiable example](http://stackoverflow.com/help/mcve)
   this will help us understand the issue.

* insert your commands here *
```

• What did you expect to occur after running these commands?

* insert here *

• What actually happened instead?

* insert here *

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

* insert URL here *

[rimrul]

The pdf, as with #2427 isn't all that usefull. The Excel file on the other hand at least contains information about what components have alleged vulnerabilities. While we'd still have prefered this information to be in the actual issue text, here's what the Excel boils down to:

|Component|Version|Vulnerability count|Object|Object full path|
|---|---|---|---|---|
|cyrus-sasl|2.1.27|1|msys-sasl2-3.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-sasl2-3.dll|
|file|5,37|1|msys-magic-1.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-magic-1.dll|
|heimdal|7.5.0|2|msys-krb5-26.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-krb5-26.dll|
|libssh2|1.9.0|1|libssh2-1.dll|Git-2.24.1.2-64-bit.exe:app/mingw64/bin/libssh2-1.dll|
|libssh2|1.9.0|1|msys-ssh2-1.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-ssh2-1.dll|
|libxslt||1|msys-xslt-1.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-xslt-1.dll|
|openssl|1.0.2p|7|ssleay32.dll|Git-2.24.1.2-64-bit.exe:app/mingw64/bin/ssleay32.dll|
|openssl|1.0.2p|7|libeay32.dll|Git-2.24.1.2-64-bit.exe:app/mingw64/bin/libeay32.dll|
|openssl|1.0.2p|7|msys-crypto-1.0.0.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-crypto-1.0.0.dll|
|openssl|1.0.2p|7|msys-ssl-1.0.0.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-ssl-1.0.0.dll|
|openssl|1.1.1d|1|libcrypto-1_1-x64.dll|Git-2.24.1.2-64-bit.exe:app/mingw64/bin/libcrypto-1_1-x64.dll|
|openssl|1.1.1d|1|libssl-1_1-x64.dll|Git-2.24.1.2-64-bit.exe:app/mingw64/bin/libssl-1_1-x64.dll|
|openssl|1.1.1d|1|msys-ssl-1.1.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-ssl-1.1.dll|
|openssl|1.1.1d|1|msys-crypto-1.1.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-crypto-1.1.dll|
|patch|2.7.6|7|patch.exe|Git-2.24.1.2-64-bit.exe:app/usr/bin/patch.exe|
|perl|5.26.2|5|msys-perl5_26.dll|Git-2.24.1.2-64-bit.exe:app/usr/lib/perl5/core_perl/CORE/msys-perl5_26.dll|
|perl|5.26.2|5|msys-perl5_26.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-perl5_26.dll|
|sqlite3|3.25.3|4|sqlite3253.dll|Git-2.24.1.2-64-bit.exe:app/mingw64/lib/sqlite3.25.3/sqlite3253.dll|
|sqlite3|3.28.0|3|msys-sqlite3-0.dll|Git-2.24.1.2-64-bit.exe:app/usr/bin/msys-sqlite3-0.dll<
|zlib|1.2.8|4|Zlib.dll|Git-2.24.1.2-64-bit.exe:app/usr/lib/perl5/core_perl/auto/Compress/Raw/Zlib/Zlib.dll|

I've omitted a couple not that usefull columns, such as empty columns, license, compilation date, etc, as well as components w/o alledged vulnerabilities. What stands out to me is, that we apparently ship two versions of openssl and sqlite. Could (and should?) we unify that?

[landstander668]

Since neither file contains any indication of what alleged vulnerability exists for any item, I don't think this issue is even remotely actionable. Without significant further information, there's simply nothing to be done.

[dlk-pavan]

Hi, What additional information is needed please let me know I will share you the requested details.

[dscho]

What stands out to me is, that we apparently ship two versions of openssl and sqlite. Could (and should?) we unify that?

We ship two versions: MINGW and MSYS2 ones. The MINGW ones are dependencies e.g. by git.exe (or git-remote-https.exe). The MSYS2 ones are dependencies of git svn. So we really need both.

our security team has issued attached vulnerabilities report.

@dlk-pavan this is not really a vulnerability report, but rather a very terse summary. It does not even list any actionable information. Please provide those omitted bits and pieces.

For example, your Excel sheet (that a prolific Git for Windows contributor _had to spend valuable time processing_ to put it into a remotely usable form) lists OpenSSL v1.1.1d no less than four times. Yet https://www.openssl.org/news/newslog.html lists that version as the newest one in the v1.1.x release train. So it seems that you are not happy with the latest release at all? What exactly is your security team expecting to happen here? Should we conjure a new OpenSSL version out of thin air?

As to why ee ship OpenSSL v1.0.2p files, that is easily explained: for some time, there was a component that relied on OpenSSL v1.0.x, and to support that component while we were switching other components to v1.1.x already, we shipped both. The v1.0.2p files are not actually needed any longer, but since nothing in Git for Windows actually uses them, they hardly constitute any vulnerability.

So again @dlk-pavan: please complete your (as yet very incomplete) security report to include _concrete_ complaints (not just versions, but actually the information _what_ vulnerability you observe, exactly) as well as actionable suggestions how to fix them.

[dscho]

What additional information is needed

@dlk-pavan see the reply of @landstander668:

neither file contains any indication of _what_ alleged vulnerability exists for any item

The indication of _what_ alleged vulnerability exists, for every item, is precisely the additional information that your report omitted, and that would be needed to make this a valid report.

[dlk-pavan]

OK, I will check with my team on the details requested and update you back.

[dscho]

The pdf, as with #2427 isn't all that usefull.

@dlk-pavan by the way, could you please keep such advice in mind before offering _yet_ another .pdf? It would be really good to act on suggestions such as "please provide this information in a better format".

[rimrul]

We ship two versions: MINGW and MSYS2 ones. The MINGW ones are dependencies e.g. by git.exe (or git-remote-https.exe). The MSYS2 ones are dependencies of git svn. So we really need both.

That isn't quite what I intended to ask. I was thinking along the lines of could we build both against 3.28 (or 3.30 for that matter).

The v1.0.2p files are not actually needed any longer

So we could drop them to keep things a little smaller and a little less convoluted?

[The] Excel sheet […] lists OpenSSL v1.1.1d no less than four times.

That seems to because it scans the files one at a time and finds openssl 1.1.1d in four locations without accounting for duplicates. I'd guess our heavy use of hard links and the duplications due to MSYS2/MinGW aren't a common occurence for this tool.

The indication of what alleged vulnerability exists, for every item, is precisely the additional information that your report omitted, and that would be needed to make this a valid report.

Looking at the heimdal release notes, the heimdal vulnerabilities seem to be CVE-2018-16860 and CVE-2019-12098, both fixed in 7.6.0 (and newer).

[rimrul]

CVE's seem to be what this counts. libssh2 1.9.0 (newest release) seems to have one CVE: CVE-2019-17498

[dscho]

We ship two versions: MINGW and MSYS2 ones. The MINGW ones are dependencies e.g. by git.exe (or git-remote-https.exe). The MSYS2 ones are dependencies of git svn. So we really need both.

That isn't quite what I intended to ask. I was thinking along the lines of could we build both against 3.28 (or 3.30 for that matter).

We actually consume the SQLite artifacts from MSYS2, as there is no good reason to have Git-specific versions of them. So whatever MSYS2 provides, we consume.

The v1.0.2p files are not actually needed any longer

So we could drop them to keep things a little smaller and a little less convoluted?

Yes. The trick there, I think, is to drain https://github.com/git-for-windows/build-extra/blob/master/keep-despite-upgrade.txt.

The indication of what alleged vulnerability exists, for every item, is precisely the additional information that your report omitted, and that would be needed to make this a valid report.

Looking at the heimdal release notes, the heimdal vulnerabilities seem to be CVE-2018-16860 and CVE-2019-12098, both fixed in 7.6.0 (and newer).

Heimdal is something we _do_ build ourselves (I think it was do get rid of that libdb dependency). As far as I can tell, this is only used for Kerberos authentication, and as our Heimdal builds are only in the MSYS2 part, I would expect that to only affect git svn. Now, I am not aware of _anybody_ using Subversion repositories with Kerberos authentication, but I imagine that there might be a handful.

In other words, I do not deem this particular instance as absolutely "drop everything else" critical.

CVE's seem to be what this counts. libssh2 1.9.0 (newest release) seems to have one CVE: CVE-2019-17498

Well, don't you know, there is no way to use git.exe in a way that uses libssh2. Unless you build a Git alias that calls curl that accesses a remote SSH server, that is, which I would deem safely outside of Git for Windows' supported use cases.

So the longer I think about this here ticket, the more I am convinced that the amount of work done y you, @rimrul, by @landstander668 and myself, is most likely wasted for no good reason. Hopefully we can expect more diligence in the future before such a ticket is even raised.

[MikeWilliams-UK]

On installation I get the following WatchGuard warning for file "C:\Program Files\Git\usr\bin\strace.exe" Git appears to work ok.

What is this file for?
Why / how does Git still work if this file has been quarantined?

C:\> git --version --build-options

git version 2.24.1.windows.2
cpu: x86_64
built from commit: 992f0773022527b1b0cb1e0c13aec97dd5248053
sizeof-long: 4
sizeof-size_t: 8

C:\> cmd.exe /c ver

Microsoft Windows [Version 10.0.18362.535]

C:\> type "C:\Program Files\Git\etc\install-options.txt"

Editor Option: Notepad++
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Interactive Add: Disabled

[rimrul]

What is this file for?
Why / how does Git still work if this file has been quarantined?

https://en.m.wikipedia.org/wiki/Strace

I'm not sure we actually need strace. It might be part of a larger package that we need parts of and don't filter strict enough.

I get the following WatchGuard warning

Again, absolutely no information as to what's allegedly wrong with the file, beyond "it's a threat".

[dscho]

What is this file for?
Why / how does Git still work if this file has been quarantined?

https://en.m.wikipedia.org/wiki/Strace

I'm not sure we actually need strace. It might be part of a larger package that we need parts of and don't filter strict enough.

We don't need strace.exe at all. It is just a convenient tool for diagnosing MSYS2 issues.

I get the following WatchGuard warning

Again, absolutely no information as to what's allegedly wrong with the file, beyond "it's a threat".

Oh, I know what it threatens: it threatens to eat up my time for nothing in return 😀

[MikeWilliams-UK]

Thanks, @dscho good to know for sure that what our IT departments filtering system is nobbling is not required for day to day operations :-)

[dscho]

good to know for sure that what our IT departments filtering system is nobbling is not required for day to day operations

@MikeWilliams-UK if your IT department really only churns out threat warnings with no actionable content, then you need to get a new IT department.

I had the pleasure of working with real professionals during the past four months (most of the security fixes that went into v2.24.1, including eight of the nine CVEs, were due to actionable reports by an IT department worth their salt). So I do have a bit of experience with good IT departments.

If you show me a good bug report, I will always listen. If you show me a good security bug report, you will have my full attention. If you show me something that claims to be a bug report but is actually a shoddy bullet list that contains the word "threat" multiple times without bothering to specify what that threat is supposed to be, then I will always send you back to do your homework properly.

Hopefully this clarifies the situation and my stance? We are talking about Git for Windows, after all, which is a vital part of professional software development, not some hobby project where you can be sloppy. Therefore, I really want professional (or at least _good_) reports that have been written with care and diligence.

[MikeWilliams-UK]

@dscho to be fair to the IT dept it's the program which is dishing out the very unhelpful message I copied earlier. There is no chance to "ask" the program why it quaranteened the program.
I will report it to them so that they can take this up with the vendors.

[dlk-pavan]

Hi,

Attaching the git-22412-64-bitexe-vulnerabilities which has more details about the vulnerabilities. Please check and help to solve the vulnerabilities for us.

Thanks in Advance.
git-22412-64-bitexe-vulnerabilities.xlsx

[dscho]

I will report it to them so that they can take this up with the vendors.

@MikeWilliams-UK That's their job. Every IT department needs to make sure they have tools that help them keep their users safe. If those tools do not fulfill that mission in life, they need to be improved.

Just think about the bug reports the Git project would get if git commit failed with the commit message could not commit. and nothing else? That's precisely how bad this tool you talk about seems to be (unless the threat sync level in the UI is actually a link to more information, in which case the tool would not be at fault for the failure to convey that information in this here bug report).

Attaching the git-22412-64-bitexe-vulnerabilities which has more details about the vulnerabilities. Please check and help to solve the vulnerabilities for us.

@dlk-pavan do you really force @rimrul again to unroll this attachment? I hoped that you would have learned by now that attachments are a bad way to convey this information. It is a pure waste of everybody's time not to prepare the information in the format expected on this bug tracker. And it is not like I have spent zero time on this ticket already. I have spent more than half an hour, for _nothing_ valuable in return.

[chrisbra]

I have markdown'ed the excel file:

https://gist.github.com/chrisbra/55bf22d7b2fa3ad6b8e4d25f5871a674

[dscho]

@chrisbra thank you for doing @dlk-pavan's homework assignment.

[dscho]

cyrus-sasl: CVE-2019-19906

This vulnerability seems to affect only LDAP-based authentication. As this component is only used in git svn, there _might_ be a vulnerability there. Seeing as the usage of git svn declined substantially over the last decade, and not seeing any indication that it is used in conjunction with LDAP-based authentication, I deem this _very_ low priority.

file: CVE-2019-18218

A missing test allows an out-of-bounds write when parsing malformed Composite Document Files (the format used in Microsoft Office document files before they switched to zipped XML). The file utility is included only for convenience, and is not used by Git for Windows. Therefore, once again, the priority is very low.

Side note: the Excel sheet lists "5,35" as latest version, which is incorrect. It is v5.38.

heimdal: CVE-2019-16860, CVE-2019-12098

CVE-2019-16860 does not even talk about heimdal, but about an application called Code42. What the heck.

CVE-2019-12098 on the other hand _does_ talk about a rather critical problem in the Kerberos client that is used by git svn. As mentioned in the comment about cyrus-sasl, the usage of git svn declined dramatically, and while there _have_ been mentions of users accessing Subversion repositories using Kerberos authentication, the overall usage of this seems to be super low. Therefore once again, this has low priority.

libssh2: CVE-2019-17498

A bug in libssh2 allows maliciously-crafted SSH servers to learn more about the client than they should be allowed to.

This library is only used in the MSYS version of cURL which is only bundled because it is a dependency of GNU Privacy Guard. While it is probably technically possible to trick GNU Privacy Guard into trying to access an SSH server, this is such an improbably attack vector that I won't even bother assigning a priority.

libxml2: CVE-2019-19956

The file msys-gettextlib-0-19-8-1.dll is mistakenly assumed to be included in libxml2. It is not. It is part of the gettext package.

The CVE mentions a memory leak and for the love of this world, I cannot think of any reason why it was assigned the rather alarming score 7.5 High.

In any case, this component is included in Git for Windows only because it is marked as a transitive dependency of GNU Privacy Guard in MSYS2 (which is like no longer correct). So there is not actually any need to address this in Git for Windows.

openssl: CVE-2019-1551

(Omitting the entries for v1.0.2p because the files are not actually used, and they won't be included in future versions as of https://github.com/git-for-windows/build-extra/commit/27f84035849421d6c6ec7dffb2db2506a5311a6f)

There is a buffer overflow in x86-64-specific code that was classified as low by the OpenSSL team:

[...] attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway.

OpenSSL is actually used both in git svn and in the HTTPS-related parts of Git for Windows. But the OpenSSL team considers this bug _so_ uncritical that they did not even bother publishing a new version. We do pick up OpenSSL versions very quickly, anyway, so that would have been surprising if we had failed to upgrade.

patch: CVE-2015-1396, CVE-2018-6951, CVE-2018-6952, CVE-2018-20969, CVE-2018-100015, CVE-2019-13636, CVE-2019-13638

CVE-2015-1396 is misclassified as affecting v2.7.6: it was fixed in v2.7.3 according to https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-1396. CVE-2018-6951 says that a mangled patch file can cause a crash. CVE-2018-6952 talks about a double-free upon incorrect input. CVE-2018-20969 talks about remote code execution when a special-crafted file is passed to patch. CVE-2018-1000156 is not even known by the NIST database, but appears to have been used at some stage to describe CVE-2018-20969. CVE-2019-13636 talks about a bug when following symlinks. CVE-2019-13638 appears to be _yet_ another duplicate of 20969.

Git for Windows does not use patch, though, it is included in the distribution purely for users' convenience. Besides, there has not been _any_ official release since v2.7.6. If you feel strongly about these issues, please go pester the GNU patch team. Or, much, much better: invest a little bit of your time and money to fix the problem. This would have the further benefit of giving something back (you did not pay for this software, after all).

perl: CVE-2018-18311, CVE-2018-18312, CVE-2018-18313, CVE-2018-18314, CVE-2018-12015

CVE-2018-12015 talks about a vulnerability in Archive::Tar. CVE-2018-18311 talks about incorrect handling of regular expressions potentially resulting in invalid writes. CVE-2018-18312, CVE-2018-18313 and CVE-2018-18314 and are more of the same.

Not even contrib/fast-import/import-tars.perl uses Archive::Tar, and that is the closest Git comes to that Perl module. None of the Git commands implemented in Perl use regular expressions from untrusted sources (unless you consider Git users to be untrusted, which Git does distinctly not). Besides, apart from git svn, there only Git commands that are implemented as Perl scripts are the CVS/GNU Arch related "foreign SCM integrators" and git add -i, git add -p and git send-email. Apart from the increasingly unused foreign SCM integration commands, the only Perl script of those that actually even _talks_ to possibly untrusted sources is git send-email and I am _quite_ certain that it won't just receive a regular expression from a remote mail server and then executes it.

In other words, while I agree that we should try to upgrade to Perl v5.30.0, it is a ton of work and given that it is not actually pressing at all, it is very much down my list.

sqlite3: CVE-2019-8457, CVE-2019-16168, CVE-2019-19646

CVE-2019-8457 talks about a potential out-of-bound read. CVE-2019-16168 says that SQLite could be crashing the application on reading crafted databases. CVE-2019-19646 says that certain queries on certain generated columns.

The only users of SQLite in Git for Windows are git svn and GNU Privacy Guard. Given the simplicity of the involved databases, I would be _highly_ surprised if we were vulnerable to any practical attack vector there.

zlib: CVE-2016-9840, CVE-2016-9841, CVE-2016-9842, CVE-2016-9843

CVE-2016-9840 details that uncompressing maliciously-crafted files can have "unspecified impact". CVE-2016-9841 and CVE-2016-9842 is more of the same. CVE-2016-9843 talks about CRC32 being vulnerable.

First of all, the only vulnerable zlib component is included in the Perl modules, the other two instances of the zlib files are already built from v1.2.11, i.e. the latest. Now, the only time Git seems to use the Zlib Perl module is to compress the log files in git svn. It is hard to imagine any way how a malicious Subversion repository would need to be crafted to cause any plausible attack vector there.

Summary

None of the reported issues are critical. At best, they seem to be very low priority.

Please note that I used only public sources to figure all of this out. Read: you did not need _me_ to do that. The CVEs are in the NIST database. The paths of the affected files tell you whether they are used by the MSYS components in Git for Windows (which are used to run GNU Privacy Guard, the Unix shell and Perl scripts, of which there are only a handful any longer, look for the .sh and .perl files in https://github.com/git/git), whether they are used by the MINGW components (which are infinitely more interesting because they are used to run the core of Git for Windows, including most crucially the cURL-backed HTTPS transport) or Perl (which is mostly uninteresting as there is a decreasing number of Perl scripts, git svn having been the most prominent one and that is falling largely into disuse).

[dlk-pavan]

HI,

Could you please let us know when the above listed vulnerabilities will be fixed?

Thanks

[dscho]

@dlk-pavan how can you ask such a question? Have you read any of my carefully crafted reply???

[dscho]

So to make things utterly clear: the Git for Windows project is not a "users demand, the maintainer delivers" project. Distinctly not.

You would have to pay me a _ton_ of money to make me agree that you are entitled to demand _anything_ from me, and you haven't not in terms of money, not in terms of contributions, I would actually argue to the contrary: you received a lot of value from me and now it is your turn to give back. Of course, you have no contractual obligation to give me anything, but _do_ keep in mind that neither do I have any obligation to give you anything. @dlk-pavan your tone seems to suggest that you are under the incorrect impression that I owe you anything.

Git for Windows is an _open source_ project. Which means that it is as good as the contributions it receives. We get some really good contributions from time to time. As to your ticket, @dlk-pavan : sSure, from time to time other contributors feel compelled to fix an issue you reported, but oftentimes nobody else is interested as much as you are to fix it. (Speaking for myself, as I outlined in my analysis above, I do not deem any of those issues you reported critical enough for me to get involved, their resolution definitely does not even require my expertise.)

That means: @dlk-pavan it is _your own_ responsibility to drive this ticket to resolution. If you want to see those issues fixed, I provided ample information how to go about it. If any part of it is still unclear, do not hesitate to ask for more guidance. If you leave those issues unaddressed, you merely express that you do not deem them important enough, either.

[dlk-pavan]

Hi Dscho,

Thanks for your message.

We have bought 35 GITHUB licenses and we are in process of Installing GIT for windows and found these issues. Elio Gambetta [e-mail] has suggested to create a ticket here so that the resolution would be provided.

So, Please let us know how to progress on this?

Thanks.

[rimrul]

Let me make this clear.

• We are not github. We don't care what goods and services were purchased from github.

• You have a list of the affected dependencies and what vulnerabilities affect each.

  • For those where a new fixed version exists, you'd need to contribute a PR to update our packages to that version.

  • For those where no fixed version exists, you'd need to contribute a fix to that project, wit for their next release and then contribute a PR to update our packages.

Alternatively you could wait for someone who cares about these vulnerabilities more than you do, but let me give you the quick summary of our maintainers analysis:

None of the reported issues are critical. At best, they seem to be very low priority.

[dscho]

I will leave this open for another couple of days just in case @dlk-pavan decides to act on the suggestions how they could address the raised concerns.

[dscho]

Okay, I am really growing tired of waiting.